Re: [Rd] [R] which.na
> "CAPE" == Charles Annis, P E > on Thu, 19 Mar 2009 22:46:10 -0400 writes: >> ?is.na >> x <- c(NA, 3, 4, 5, NA) >> which(is.na(x)) CAPE> [1] 1 5 well, of course. But note that which.na(.) could be implemented to be faster (because needing much less memory) than the above, notably when x is large and has only few NAs But this now has *REALLY* changed into a topic belonging to R-devel, not R-help --> hence I've diverted the thread to there. I have recently entertained similar thoughts, i.e. wished for R functions that compute which( function_returning_logical(..) ) and also any( function_returning_logical(..) ) directly {on .Internal i.e. C-level} instead of going to construct the potentially huge logical vector. For what functions should this happen? I agree that is.na() is one of them; but then, why not is.nan() / is.finite() too? Instead of defining a slew of such functions which.foo(), which.bar(), any.foo(), any.bar(), etc, it would be nice to have a generic interface such as whichApply(x, is.na) whichApply(x, is.nan) anyApply(x, is.na) where internally, for some functions {in a given internal table}, the fast shortcut would be used, and for others the interface would be equivalent to which( thatFunction( x ) ) Martin Maechler, ETH Zurich (and R Core team) CAPE> Charles Annis, P.E. CAPE> charles.an...@statisticalengineering.com CAPE> phone: 561-352-9699 CAPE> eFax: 614-455-3265 CAPE> http://www.StatisticalEngineering.com CAPE> -Original Message- CAPE> From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On CAPE> Behalf Of Santosh CAPE> Sent: Thursday, March 19, 2009 9:37 PM CAPE> To: r-h...@r-project.org CAPE> Subject: [R] which.na CAPE> Hi R- users CAPE> I was wondering if there is any function equivalent to which.na used in S+? CAPE> Thanks much in advance! CAPE> Regards, CAPE> Santosh CAPE> [[alternative HTML version deleted]] CAPE> __ CAPE> r-h...@r-project.org mailing list CAPE> https://stat.ethz.ch/mailman/listinfo/r-help CAPE> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html CAPE> and provide commented, minimal, self-contained, reproducible code. CAPE> __ CAPE> r-h...@r-project.org mailing list CAPE> https://stat.ethz.ch/mailman/listinfo/r-help CAPE> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html CAPE> and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] which.na
Martin Maechler wrote: "CAPE" == Charles Annis, P E on Thu, 19 Mar 2009 22:46:10 -0400 writes: >> ?is.na >> x <- c(NA, 3, 4, 5, NA) >> which(is.na(x)) CAPE> [1] 1 5 well, of course. But note that which.na(.) could be implemented to be faster (because needing much less memory) than the above, notably when x is large and has only few NAs But this now has *REALLY* changed into a topic belonging to R-devel, not R-help --> hence I've diverted the thread to there. I have recently entertained similar thoughts, i.e. wished for R functions that compute which( function_returning_logical(..) ) and also any( function_returning_logical(..) ) directly {on .Internal i.e. C-level} instead of going to construct the potentially huge logical vector. For what functions should this happen? I agree that is.na() is one of them; but then, why not is.nan() / is.finite() too? Instead of defining a slew of such functions which.foo(), which.bar(), any.foo(), any.bar(), etc, it would be nice to have a generic interface such as whichApply(x, is.na) whichApply(x, is.nan) anyApply(x, is.na) where internally, for some functions {in a given internal table}, the fast shortcut would be used, and for others the interface would be equivalent to which( thatFunction( x ) ) A couple of different interfaces to the same idea: - which() could recognize a few thatFunction(x) calls before evaluating them, and do the fast internal version. (This is hard because it needs to know that the user hasn't redefined is.na, etc. Probably not worth doing.) - which() could gain a new arg, so that which(x, test=is.na) would do as your whichApply() does. Duncan Murdoch Martin Maechler, ETH Zurich (and R Core team) CAPE> Charles Annis, P.E. CAPE> charles.an...@statisticalengineering.com CAPE> phone: 561-352-9699 CAPE> eFax: 614-455-3265 CAPE> http://www.StatisticalEngineering.com CAPE> -Original Message- CAPE> From: r-help-boun...@r-project.org [mailto:r-help-boun...@r-project.org] On CAPE> Behalf Of Santosh CAPE> Sent: Thursday, March 19, 2009 9:37 PM CAPE> To: r-h...@r-project.org CAPE> Subject: [R] which.na CAPE> Hi R- users CAPE> I was wondering if there is any function equivalent to which.na used in S+? CAPE> Thanks much in advance! CAPE> Regards, CAPE> Santosh CAPE> [[alternative HTML version deleted]] CAPE> __ CAPE> r-h...@r-project.org mailing list CAPE> https://stat.ethz.ch/mailman/listinfo/r-help CAPE> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html CAPE> and provide commented, minimal, self-contained, reproducible code. CAPE> __ CAPE> r-h...@r-project.org mailing list CAPE> https://stat.ethz.ch/mailman/listinfo/r-help CAPE> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html CAPE> and provide commented, minimal, self-contained, reproducible code. __ 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 R with java
Hi, In order to do this you should use JRI (Java R Interface). Note, you should first download rJava package within which you can find the JRI library. Good luck! RMP Bilel Masmoudi wrote: > > Hi, >> >> I am a java programmer, an I want to use R from java. >> could so help me >> thanks for telling me whether I 'm using the good mailing list. >> >> thanks!! >> >> >> > > > -- > Bilel > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- View this message in context: http://www.nabble.com/Re%3A-using-R-with-java-tp22598392p22598846.html Sent from the R devel mailing list archive at Nabble.com. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] v2.8.1 crashes on quit(save="yes") or just won't save (PR#13612)
Full_Name: Anne Gilman Version: 2.8.1 OS: Mac OS X 10.4.11 Submission from: (NULL) (132.177.75.245) Dear R Team, Today I upgraded from R 2.2.2 to 2.8.1 ...then I restarted, did a bunch of work, and tried to quit. (Note that I have oodles of stuff saved in the work environment; took almost a full minute to start up.) After over 10 minutes, it was still trying to close up, and the problem (below) for DBfetch was mentioned, plus it said *** caught segfault *** address 0x7fffdeb1 cause 'memory not mapped' (retyped from my notes, no way to grab) After about five more minutes, I did a Force Quit. Then I reproduced the bug. I opened R, loaded a CSV file from my previous day's work, then quit - here's what happened: > quit(save="yes") Error in .Call("R_lazyLoadDBfetch", key, file, compressed, hook, PACKAGE = "base") : C symbol name "R_lazyLoadDBfetch" not in DLL for package "base" > quit(save="no") (that latter command worked, 2nd time, no need for Force Quit) Yarg! I know I can work around this using write.csv(), but I guess my lesson is never to change versions in the middle of one's dissertation analyses! with thanks, Anne G. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sprintf causes a segfault (PR#13613)
Full_Name: Wacek Kusnierczyk Version: 2.8.0 and 2.10.0 r48163 OS: Ubuntu 8.04 Linux 32bit Submission from: (NULL) (129.241.198.172) the following code illustrates a problem with sprintf which consistently causes a segfault when applied to certain type of arguments. it also shows inconsistent consequences of the segfault: (e = tryCatch(stop(), error=identity)) # e is an error object sprintf('%d', e) # error in sprintf("%d", e) : unsupported type sprintf('%f', e) # error in sprintf("%f", e) : (list) object cannot be coerced to type 'double' sprintf('%s', e) # segfault reported, with a choice of options for how to exit the session it is possible not to leave the session, by simply typing ^c (ctrl-c). (which should probably be prohibited.) if one stays in the session, then trying to evaluate sprintf('%s', e) will cause a segfault with immediate crash (r is silently closed), but not necessarily if some other code is executed first. in the latter case, there may be no segfault, but an error message might be printed instead: e = tryCatch(stop(), error=identity) sprintf('%s', e) # segfault, choice of options # ^c, stay in the session e = tryCatch(stop(), error=identity) sprintf('%s', e) # segfault, immediate exit e = tryCatch(stop(), error=identity) sprintf('%s', e) # segfault, choice of options # ^c, stay in the session e = tryCatch(stop(), error=identity) x = 1 # possibly, whatever code would do sprintf('%s', e) # [1] "Error in doTryCatch(return(expr), name, parentenv, handler): \n" # [2] "Error in doTryCatch(return(expr), name, parentenv, handler): \n" sprintf('%s', e) # segfault, immediate exit in the second code snippet above, on some executions the error message was printed. on others a segfault caused immediate exit. (the pattern seems to differ between 2.8.0 and 2.10.0-devel.) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] which.na
There are many other useful extensions one might imagine along these lines. For instance, we could have an argument for stopping the 'which' calculation at the first result (or the first N results), which is often useful (cf. any). But I think it would be much cleaner for things like this to be done in a compiler. I suppose another possibility would be to have low-level interfaces like which(a, test=xxx, count=nnn) which could be used for optimization or for a source-to-source optimizer. -s On Fri, Mar 20, 2009 at 6:28 AM, Duncan Murdoch wrote: > Martin Maechler wrote: >>> >>> "CAPE" == Charles Annis, P E >>> >>> on Thu, 19 Mar 2009 22:46:10 -0400 writes: >>> >> >> >> ?is.na >> >> x <- c(NA, 3, 4, 5, NA) >> >> which(is.na(x)) >> CAPE> [1] 1 5 >> >> well, of course. >> >> But note that which.na(.) could be implemented to be faster (because >> needing much less memory) than the above, >> notably when x is large and has only few NAs >> >> But this now has *REALLY* changed into a topic belonging to >> R-devel, not R-help >> >> --> hence I've diverted the thread to there. >> >> I have recently entertained similar thoughts, i.e. wished for R >> functions that compute which( function_returning_logical(..) ) >> and also >> any( function_returning_logical(..) ) >> >> directly {on .Internal i.e. C-level} instead of going to >> construct the potentially huge logical vector. >> >> For what functions should this happen? >> I agree that is.na() is one of them; but then, why not >> is.nan() / is.finite() too? >> >> Instead of defining a slew of such functions which.foo(), which.bar(), >> any.foo(), any.bar(), etc, >> it would be nice to have a generic interface such as >> >> whichApply(x, is.na) >> whichApply(x, is.nan) >> >> anyApply(x, is.na) >> where internally, for some functions {in a given internal >> table}, the fast shortcut would be used, and for others the >> interface would be equivalent to which( thatFunction( x ) ) >> > > A couple of different interfaces to the same idea: > > - which() could recognize a few thatFunction(x) calls before evaluating > them, and do the fast internal version. (This is hard because it needs to > know > that the user hasn't redefined is.na, etc. Probably not worth doing.) > > - which() could gain a new arg, so that > > which(x, test=is.na) > > would do as your whichApply() does. > > Duncan Murdoch >> >> Martin Maechler, ETH Zurich (and R Core team) >> >> >> CAPE> Charles Annis, P.E. >> >> CAPE> charles.an...@statisticalengineering.com >> CAPE> phone: 561-352-9699 >> CAPE> eFax: 614-455-3265 >> CAPE> http://www.StatisticalEngineering.com >> >> CAPE> -Original Message- >> CAPE> From: r-help-boun...@r-project.org >> [mailto:r-help-boun...@r-project.org] On >> CAPE> Behalf Of Santosh >> CAPE> Sent: Thursday, March 19, 2009 9:37 PM >> CAPE> To: r-h...@r-project.org >> CAPE> Subject: [R] which.na >> >> CAPE> Hi R- users >> >> CAPE> I was wondering if there is any function equivalent to which.na >> used in S+? >> >> CAPE> Thanks much in advance! >> >> CAPE> Regards, >> CAPE> Santosh >> >> CAPE> [[alternative HTML version deleted]] >> >> CAPE> __ >> CAPE> r-h...@r-project.org mailing list >> CAPE> https://stat.ethz.ch/mailman/listinfo/r-help >> CAPE> PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> CAPE> and provide commented, minimal, self-contained, reproducible >> code. >> >> CAPE> __ >> CAPE> r-h...@r-project.org mailing list >> CAPE> https://stat.ethz.ch/mailman/listinfo/r-help >> CAPE> PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> CAPE> and provide commented, minimal, self-contained, reproducible >> code. >> >> __ >> 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
Re: [Rd] v2.8.1 crashes on quit(save="yes") or just won't save (PR#13612)
anne.gil...@gmail.com wrote: Full_Name: Anne Gilman Version: 2.8.1 OS: Mac OS X 10.4.11 Submission from: (NULL) (132.177.75.245) Dear R Team, Today I upgraded from R 2.2.2 to 2.8.1 ...then I restarted, did a bunch of work, and tried to quit. (Note that I have oodles of stuff saved in the work environment; took almost a full minute to start up.) After over 10 minutes, it was still trying to close up, and the problem (below) for DBfetch was mentioned, plus it said *** caught segfault *** address 0x7fffdeb1 cause 'memory not mapped' (retyped from my notes, no way to grab) After about five more minutes, I did a Force Quit. Then I reproduced the bug. I opened R, loaded a CSV file from my previous day's work, then quit - here's what happened: quit(save="yes") Error in .Call("R_lazyLoadDBfetch", key, file, compressed, hook, PACKAGE = "base") : C symbol name "R_lazyLoadDBfetch" not in DLL for package "base" The error message sounds like you mixed up an installation with new R-2.8.1 and some old packages (maybe including base itself?!) that are still in some library you are loading packages from. Please do a clean installation and update all you packages. If you have a separate library than the standard one, please remove all base packages from that library. Uwe Ligges quit(save="no") >> (that latter command worked, 2nd time, no need for Force Quit) Yarg! I know I can work around this using write.csv(), but I guess my lesson is never to change versions in the middle of one's dissertation analyses! with thanks, Anne 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
Re: [Rd] R does not compile any more on FreeBSD 8.0-CURRENT
On 19.03.2009 10:37 (UTC+1), Hiroyuki Kawakatsu wrote: Rainer Hurling wrote: On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: [...] I run 7.1-RELEASE (amd64) so I cannot comment on any potential issues with 8.0-CURRENT. On my machine the r-devel tarball (r48148) builds without any problems but I use ./configure MAKE=gmake Have you tried gmake? h. Yes, I tried gmake with same result. This behaviour is only with CURRENT from ~ 5th march 2009 on. Before that I have been able to compile with standard (bsd) make. Thank you for this question, Rainer __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] which.na
If you are considering emulating the S/S+ which.na, which.nan, etc., family of functions to save space you might also consider the related anyMissing function (I don't know why it isn't any.is.na to match the pattern). anyMissing(x) returns the same result as any(is.na(x)) or length(which.na(x)) but stops scanning the input when it sees the first NA, saving time and space in the common idiom of stopifnot(!any(is.na(x))). (BTW, Should R have a stopif() function to avoid that double negative?) Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com > -Original Message- > From: r-devel-boun...@r-project.org > [mailto:r-devel-boun...@r-project.org] On Behalf Of Martin Maechler > Sent: Friday, March 20, 2009 2:46 AM > To: charles.an...@statisticalengineering.com > Cc: 'Santosh'; r-de...@stat.math.ethz.ch > Subject: Re: [Rd] [R] which.na > > > "CAPE" == Charles Annis, P E > > > on Thu, 19 Mar 2009 22:46:10 -0400 writes: > > >> ?is.na > >> x <- c(NA, 3, 4, 5, NA) > >> which(is.na(x)) > CAPE> [1] 1 5 > > well, of course. > > But note that which.na(.) could be implemented to be > faster (because needing much less memory) than the above, > notably when x is large and has only few NAs > > But this now has *REALLY* changed into a topic belonging to > R-devel, not R-help > > --> hence I've diverted the thread to there. > > I have recently entertained similar thoughts, i.e. wished for R > functions that compute > which( function_returning_logical(..) ) > and also > any( function_returning_logical(..) ) > > directly {on .Internal i.e. C-level} instead of going to > construct the potentially huge logical vector. > > For what functions should this happen? > I agree that is.na() is one of them; but then, why not > is.nan() / is.finite() > too? > > Instead of defining a slew of such functions > which.foo(), which.bar(), any.foo(), any.bar(), etc, > it would be nice to have a generic interface such as > >whichApply(x, is.na) >whichApply(x, is.nan) > >anyApply(x, is.na) > > where internally, for some functions {in a given internal > table}, the fast shortcut would be used, and for others the > interface would be equivalent to which( thatFunction( x ) ) > > Martin Maechler, ETH Zurich (and R Core team) > > > CAPE> Charles Annis, P.E. > > CAPE> charles.an...@statisticalengineering.com > CAPE> phone: 561-352-9699 > CAPE> eFax: 614-455-3265 > CAPE> http://www.StatisticalEngineering.com > > > CAPE> -Original Message- > CAPE> From: r-help-boun...@r-project.org > [mailto:r-help-boun...@r-project.org] On > CAPE> Behalf Of Santosh > CAPE> Sent: Thursday, March 19, 2009 9:37 PM > CAPE> To: r-h...@r-project.org > CAPE> Subject: [R] which.na > > CAPE> Hi R- users > > CAPE> I was wondering if there is any function equivalent > to which.na used in S+? > > CAPE> Thanks much in advance! > > CAPE> Regards, > CAPE> Santosh > > CAPE> [[alternative HTML version deleted]] > > CAPE> __ > CAPE> r-h...@r-project.org mailing list > CAPE> https://stat.ethz.ch/mailman/listinfo/r-help > CAPE> PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > CAPE> and provide commented, minimal, self-contained, > reproducible code. > > CAPE> __ > CAPE> r-h...@r-project.org mailing list > CAPE> https://stat.ethz.ch/mailman/listinfo/r-help > CAPE> PLEASE do read the posting guide > http://www.R-project.org/posting-guide.html > CAPE> and provide commented, minimal, self-contained, > reproducible code. > > __ > 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] Why does the lexical analyzer drop comments ?
It happens in the token function in gram.c:    c = SkipSpace();    if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {    int c;    while ((c = xxgetc()) != '\n' && c != R_EOF) ;    if (c == R_EOF) EndOfFile = 2;    return c; } which effectively drops comments. Would it be possible to keep the information somewhere ? The source code says this:  * The function yylex() scans the input, breaking it into  * tokens which are then passed to the parser. The lexical  * analyser maintains a symbol table (in a very messy fashion). so my question is could we use this symbol table to keep track of, say, COMMENT tokens. Why would I even care about that ? I'm writing a package that will perform syntax highlighting of R source code based on the output of the parser, and it seems a waste to drop the comments. An also, when you print a function to the R console, you don't get the comments, and some of them might be useful to the user. Am I mad if I contemplate looking into this ? Romain -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does the lexical analyzer drop comments ?
On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote: It happens in the token function in gram.c:    c = SkipSpace();    if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {    int c;    while ((c = xxgetc()) != '\n' && c != R_EOF) ;    if (c == R_EOF) EndOfFile = 2;    return c; } which effectively drops comments. Would it be possible to keep the information somewhere ? The source code says this:  * The function yylex() scans the input, breaking it into  * tokens which are then passed to the parser. The lexical  * analyser maintains a symbol table (in a very messy fashion). so my question is could we use this symbol table to keep track of, say, COMMENT tokens. Why would I even care about that ? I'm writing a package that will perform syntax highlighting of R source code based on the output of the parser, and it seems a waste to drop the comments. An also, when you print a function to the R console, you don't get the comments, and some of them might be useful to the user. Am I mad if I contemplate looking into this ? Comments are syntactically the same as whitespace. You don't want them to affect the parsing. If you're doing syntax highlighting, you can determine the whitespace by looking at the srcref records, and then parse that to determine what isn't being counted as tokens. (I think you'll find a few things there besides whitespace, but it is a fairly limited set, so shouldn't be too hard to recognize.) The Rd parser is different, because in an Rd file, whitespace is significant, so it gets kept. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does the lexical analyzer drop comments ?
Peter Dalgaard wrote: Duncan Murdoch wrote: On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote: It happens in the token function in gram.c:    c = SkipSpace();    if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {    int c;    while ((c = xxgetc()) != '\n' && c != R_EOF) ;    if (c == R_EOF) EndOfFile = 2;    return c; } which effectively drops comments. Would it be possible to keep the information somewhere ? The source code says this:  * The function yylex() scans the input, breaking it into  * tokens which are then passed to the parser. The lexical  * analyser maintains a symbol table (in a very messy fashion). so my question is could we use this symbol table to keep track of, say, COMMENT tokens. Why would I even care about that ? I'm writing a package that will perform syntax highlighting of R source code based on the output of the parser, and it seems a waste to drop the comments. An also, when you print a function to the R console, you don't get the comments, and some of them might be useful to the user. Am I mad if I contemplate looking into this ? Comments are syntactically the same as whitespace. You don't want them to affect the parsing. Well, you might, but there is quite some madness lying that way. Back in the bronze age, we did actually try to keep comments attached to (AFAIR) the preceding token. One problem is that the elements of the parse tree typically involve multiple tokens, and if comments after different tokens get stored in the same place something is not going back where it came from when deparsing. So we had problems with comments moving from one end of a loop the other and the like. Ouch. That helps picturing the kind of madness ... Another way could be to record comments separately (similarly to srcfile attribute for example) instead of dropping them entirely, but I guess this is the same as Duncan's idea, which is easier to set up. You could try extending the scheme by encoding which part of a syntactic structure the comment belongs to, but consider for instance how many places in a function call you can stick in a comment. f #here ( #here a #here (possibly) = #here 1 #this one belongs to the argument, though ) #but here as well If you're doing syntax highlighting, you can determine the whitespace by looking at the srcref records, and then parse that to determine what isn't being counted as tokens. (I think you'll find a few things there besides whitespace, but it is a fairly limited set, so shouldn't be too hard to recognize.) The Rd parser is different, because in an Rd file, whitespace is significant, so it gets kept. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [SOLVED] Re: R does not compile any more on FreeBSD 8.0-CURRENT
Todays (03/20/2009) update of FreeBSD 8.0-CURRENT solved the problem. The two pathes are resolving again. So building and installing R on CURRENT works again :-) Thanks for your patience, Rainer On 17.03.2009 16:11 (UTC+1), Rainer Hurling wrote: On a recent FreeBSD 8.0-CURRENT (i386) building R (any version) breaks with the following messages: -- [...snip...] gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c wilcox.c -o wilcox.o gcc -std=gnu99 -I. -I../../src/include -I../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c signrank.c -o signrank.o rm -rf libnmath.a ar cr libnmath.a mlutils.o d1mach.o i1mach.o fmax2.o fmin2.o fprec.o fround.o ftrunc.o sign.o fsign.o imax2.o imin2.o chebyshev.o log1p.o expm1.o lgammacor.o gammalims.o stirlerr.o bd0.o gamma.o lgamma.o gamma_cody.o beta.o lbeta.o polygamma.o bessel_i.o bessel_j.o bessel_k.o bessel_y.o choose.o snorm.o sexp.o dgamma.o pgamma.o qgamma.o rgamma.o dbeta.o pbeta.o qbeta.o rbeta.o dunif.o punif.o qunif.o runif.o dnorm.o pnorm.o qnorm.o rnorm.o dlnorm.o plnorm.o qlnorm.o rlnorm.o df.o pf.o qf.o rf.o dnf.o dt.o pt.o qt.o rt.o dnt.o dchisq.o pchisq.o qchisq.o rchisq.o rnchisq.o dbinom.o pbinom.o qbinom.o rbinom.o rmultinom.o dcauchy.o pcauchy.o qcauchy.o rcauchy.o dexp.o pexp.o qexp.o rexp.o dgeom.o pgeom.o qgeom.o rgeom.o dhyper.o phyper.o qhyper.o rhyper.o dnbinom.o pnbinom.o qnbinom.o rnbinom.o dpois.o ppois.o qpois.o rpois.o dweibull.o pweibull.o qweibull.o rweibull.o dlogis.o plogis.o qlogis.o rlogis.o dnchisq.o pnchisq.o qnchisq.o dnbeta.o pnbeta.o qnbeta.o pnf.o pnt.o qnf.o qnt.o ptukey.o qtukey.o toms708.o wilcox.o signrank.o ranlib libnmath.a config.status: creating src/unix/Makefile make: /usr/local/R-devel/srcunix: No such file or directory *** Error code 2 Stop in /usr/local/R-devel/src/unix. *** Error code 1 Stop in /usr/local/R-devel/src. *** Error code 1 Stop in /usr/local/R-devel. -- The path /usr/local/R-devel/srcunix does not exist but .../src/unix/ does. As a workaround I am able to do cd src/unix make cd ../.. make A second break with the same error does occur at /usr/local/R-devel/srcmain. Again this workaround works cd src/main make cd ../.. make Now the compilation finished without another break. What could be the reason for this 'path break'? So long it seems that this error on FreeBSD 8.0-CURRENT only appears with R and no other third party software. Potentially this is an error within latest FreeBSD code (?) and I have to ask on the FreeBSD mailing list. But before I wanted to ask on r-de...@. Perhaps someone here has an idea? Any hints are very welcome. Thanks in advance, Rainer Hurling __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why does the lexical analyzer drop comments ?
Duncan Murdoch wrote: On 3/20/2009 2:56 PM, romain.franc...@dbmail.com wrote: It happens in the token function in gram.c:    c = SkipSpace();    if (c == '#') c = SkipComment(); and then SkipComment goes like that: static int SkipComment(void) {    int c;    while ((c = xxgetc()) != '\n' && c != R_EOF) ;    if (c == R_EOF) EndOfFile = 2;    return c; } which effectively drops comments. Would it be possible to keep the information somewhere ? The source code says this:  * The function yylex() scans the input, breaking it into  * tokens which are then passed to the parser. The lexical  * analyser maintains a symbol table (in a very messy fashion). so my question is could we use this symbol table to keep track of, say, COMMENT tokens. Why would I even care about that ? I'm writing a package that will perform syntax highlighting of R source code based on the output of the parser, and it seems a waste to drop the comments. An also, when you print a function to the R console, you don't get the comments, and some of them might be useful to the user. Am I mad if I contemplate looking into this ? Comments are syntactically the same as whitespace. You don't want them to affect the parsing. Well, you might, but there is quite some madness lying that way. Back in the bronze age, we did actually try to keep comments attached to (AFAIR) the preceding token. One problem is that the elements of the parse tree typically involve multiple tokens, and if comments after different tokens get stored in the same place something is not going back where it came from when deparsing. So we had problems with comments moving from one end of a loop the other and the like. You could try extending the scheme by encoding which part of a syntactic structure the comment belongs to, but consider for instance how many places in a function call you can stick in a comment. f #here ( #here a #here (possibly) = #here 1 #this one belongs to the argument, though ) #but here as well If you're doing syntax highlighting, you can determine the whitespace by looking at the srcref records, and then parse that to determine what isn't being counted as tokens. (I think you'll find a few things there besides whitespace, but it is a fairly limited set, so shouldn't be too hard to recognize.) The Rd parser is different, because in an Rd file, whitespace is significant, so it gets kept. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] throwing a "condition" when the current working directory changes
Hi, Would it make sense to throw a condition when the working directory changes, so that interested parties (such as guis can act based on the change using an appropriate calling handler), and not interested parties can just ignore it. For example, something like this: setwd <- function (dir) { out <- .Internal(setwd(dir)) setwdCondition <- simpleCondition( paste( "setwd: ", dir) ) class( setwdCondition ) <- c("setwd", "condition" ) setwdCondition$dir <- dir signalCondition( setwdCondition ) invisible( out ) } which could handled like this to have your prompt responding to changes of current directory: withCallingHandlers( f() , setwd = function(e) options( prompt = sprintf( "[%s]> ", e$dir ) ) ) Beyond the simple example, would it make sense to define a set of condition or events, or is this abusing the concept of conditions and something else should be used ? hooks ? Also, is there a way to "register" a calling handler so that it listens to every top-level command. Something like options( "error") but for handling other kinds of conditions ? Romain -- Romain Francois Independent R Consultant +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sprintf causes a segfault (PR#13613)
strangely enough, the way r handles the same sequence of expressions on different occasions varies: # fresh session 1 e = simpleError('foo') sprintf('%s', e) # segfault: address 0x202, cause memory not mapped # ^c sprintf('%s', e) # error in sprintf("%s", e) : 'getEncChar' must be called on a CHARSXP # fresh session 2 e = simpleError('foo') sprintf('%s', e) # segfault: address (nil), cause memory not mapped # ^c sprintf('%s', e) # segfault, exit note the difference in the address and how this relates to the outcome of the second execution of sprintf('%s', e) vQ waclaw.marcin.kusnierc...@idi.ntnu.no wrote: > the following code illustrates a problem with sprintf which consistently > causes > a segfault when applied to certain type of arguments. it also shows > inconsistent consequences of the segfault: > >(e = tryCatch(stop(), error=identity)) ># e is an error object > >sprintf('%d', e) ># error in sprintf("%d", e) : unsupported type > >sprintf('%f', e) ># error in sprintf("%f", e) : (list) object cannot be coerced to type > 'double' > >sprintf('%s', e) ># segfault reported, with a choice of options for how to exit the session > > it is possible not to leave the session, by simply typing ^c (ctrl-c). (which > should probably be prohibited.) if one stays in the session, then trying to > evaluate sprintf('%s', e) will cause a segfault with immediate crash (r is > silently closed), but not necessarily if some other code is executed first. > in > the latter case, there may be no segfault, but an error message might be > printed > instead: > >e = tryCatch(stop(), error=identity) >sprintf('%s', e) ># segfault, choice of options ># ^c, stay in the session >e = tryCatch(stop(), error=identity) >sprintf('%s', e) ># segfault, immediate exit > >e = tryCatch(stop(), error=identity) >sprintf('%s', e) ># segfault, choice of options ># ^c, stay in the session >e = tryCatch(stop(), error=identity) >x = 1 # possibly, whatever code would do >sprintf('%s', e) ># [1] "Error in doTryCatch(return(expr), name, parentenv, handler): \n" ># [2] "Error in doTryCatch(return(expr), name, parentenv, handler): \n" >sprintf('%s', e) ># segfault, immediate exit > > in the second code snippet above, on some executions the error message was > printed. on others a segfault caused immediate exit. (the pattern seems to > differ between 2.8.0 and 2.10.0-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