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
