Re: [Rd] Bug in R 2.7 for over long lines
On Fri, 2008-04-25 at 08:48 +0200, Soeren Sonnenburg wrote:
> While trying to fix swig & R2.7 I actually discovered that there is a
> bug in R 2.7 causing a crash (so R & swig might actually work):
>
> the bug is in ./src/main/gram.c line 3038:
>
> } else { /* over-long line */
> fixthis --> char *LongLine = (char *) malloc(nc);
> if(!LongLine)
> error(_("unable to allocate space for source line %d"),
> xxlineno);
> strncpy(LongLine, (char *)p0, nc);
> bug -->LongLine[nc] = '\0';
> SET_STRING_ELT(source, lines++,
>mkChar2((char *)LongLine));
> free(LongLine);
>
> note that LongLine is only nc chars long, so the LongLine[nc]='\0' might
> be an out of bounds write. the fix would be to do
>
> char *LongLine = (char *) malloc(nc+1);
>
> in line 3034
>
> Please fix and thanks to dirk for the debian r-base-dbg package!
Looking at the code again there seems to be another bug above this for
the MAXLINESIZE test too:
if (*p == '\n' || p == end - 1) {
nc = p - p0;
if (*p != '\n')
nc++;
if (nc <= MAXLINESIZE) {
strncpy((char *)SourceLine, (char *)p0, nc);
bug2 -->SourceLine[nc] = '\0';
SET_STRING_ELT(source, lines++,
mkChar2((char *)SourceLine));
} else { /* over-long line */
char *LongLine = (char *) malloc(nc+1);
if(!LongLine)
error(_("unable to allocate space for source line %d"),
xxlineno);
bug1 -->strncpy(LongLine, (char *)p0, nc);
LongLine[nc] = '\0';
SET_STRING_ELT(source, lines++,
mkChar2((char *)LongLine));
free(LongLine);
}
p0 = p + 1;
}
So I guess the test would be for nc < MAXLINESIZE above or to change
SourceLine to have MAXLINESIZE+1 size.
Alternatively as the strncpy manpage suggests do this for all
occurrences of strncpy
strncpy(buf, str, n);
if (n > 0)
buf[n - 1]= ’\0’;
this could even be made a makro / helper function ...
And another update: This does fix the R+swig crasher for me (tested)!
Soeren
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
Full_Name: Jakob Stoeger Version: 2.7.0 OS: ubuntu 7.10 Submission from: (NULL) (137.248.74.38) Hi! I hope, it is justified to write this email... I'm relatively new to linux, and haven't worked with r, yet, so please pardon any things I do not know... I tried installing r on my computer, and didn't manage to get the program running. After having installed littler, typing r into the bash results in following message: r: symbol lookup error: r: undefined symbol: R_Visible I found a bugreport here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686 I'm not sure, if this has anything to do with it, as it concerns rkward... Anyway, this information might come handy: my system: ubuntu 7.10 Kernel 2.6.22-14-generic GNOME 2.20.1 installed packages: r-base 2.7.0-1gutsy0 r-base-core 2.7.1gutsy0 r-cran-cluster 1.11.10-1gutsy0 r-cran-boot 1.2.32-1gutsy0 r-cran-cluster 1.11.10-1gutsy0 r-cran-codetools 0.2-0-1gutsy0 r-cran-foreign 0.8.24-1gutsy0 r-cran-kernsmooth 2.22.22-1gutsy0 r-cran-lattice 0.17-6-1gutsy0 r-cran-mgcv 1.3-30-1gutsy0 r-cran-nlme 3.1.88-1gutsy0 r-cran-rpart 3.1.41-1gutsy0 r-cran-survival 2.34-1gutsy0 r-cran-vr 7.2.41-1gutsy0 rkward 0.4.7a-1ubuntu1 r-recommended 2.7.0-1gutsy0 I can't guarantee, that this list is complete, as I don't know (yet), how to check for it... Not really relevant, but I feel that I should tell you: The university at which I study used to use SPSS. Until this term, from which on we will officially use r. Yeah! So, I hope you can help me getting r working. If I can help by doing anything, please tell me how... Also, I hope, this is a problem with r and not with my ubuntu, in which case I probably wouldn't have contacted you, if I would have known... Thank you very much! All the best, Jakob __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CircStats Bug? (PR#11266)
I have a vector of dimension 67, but CircStat circ.summary and circ.disp seems to conclude that the dimension is 1. I am new to R so maybe I'm just missing something. > dim(data) [1] 67 1 > circ.mean(data) [1] 0.2200071 > circ.summary(data) n mean.dir rho 1 1 0.2200071 43.12534 > circ.disp(data) nr rbar var 1 1 43.12534 43.12534 -42.12534 > -- Robert Mark, Ph.D. [EMAIL PROTECTED] Rupestrian CyberServicesPhone/FAX 928-526-3625 3644 N. Stone Crest St. http://www.rupestrian.com/ Flagstaff, AZ 86004-6811 USA RCS: Computer science in the service of rock art research, protection, and education. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] r for windows gui front-end error (PR#11257)
Full_Name: Ho Kim Version: 2.7.0 OS: Vista Submission from: (NULL) (137.68.61.23) I've just installed R 2.7.0 in my computer whose operating system is Windows Vista. When I first started the R program I encountered an error message about "R for Windows GUI frond-end". I've never seen error messages like this when I used old versions of R. For your information, my windows system supports Korean characters. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
> I tried installing r on my computer, and didn't manage to get the program > running. > After having installed littler, typing r into the bash results in following > message: > > r: symbol lookup error: r: undefined symbol: R_Visible > Did you invoke "r" or "R" because it is totally different *NIX sytems are case sensitive. You could also run "R --verbose" to see what's going wrong if any... Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: (PR#11273)
> I tried installing r on my computer, and didn't manage to get the program > running. > After having installed littler, typing r into the bash results in following > message: > > r: symbol lookup error: r: undefined symbol: R_Visible > Did you invoke "r" or "R" because it is totally different *NIX sytems are case sensitive. You could also run "R --verbose" to see what's going wrong if any... Best, Mathieu -- Institute of Mathematics Ecole Polytechnique Fédérale de Lausanne STAT-IMA-FSB-EPFL, Station 8 CH-1015 Lausanne Switzerland http://stat.epfl.ch/ Tel: + 41 (0)21 693 7907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
On 24 April 2008 at 20:20, [EMAIL PROTECTED] wrote:
| Full_Name: Jakob Stoeger
| Version: 2.7.0
| OS: ubuntu 7.10
| Submission from: (NULL) (137.248.74.38)
|
|
| Hi!
|
| I hope, it is justified to write this email...
| I'm relatively new to linux, and haven't worked with r, yet, so please pardon
| any things I do not know...
|
| I tried installing r on my computer, and didn't manage to get the program
| running.
| After having installed littler, typing r into the bash results in following
| message:
|
| r: symbol lookup error: r: undefined symbol: R_Visible
You need to rebuild littler ('r') against the new version of R ('R').
I did that for Debian, looks like Ubuntu could do with it too. Your R
version was provided by volunteers outside of Ubuntu.
Vincent: In a perfect world, could you rebuild littler and provide it?
Jakob: Barring a new littler you can apt-get, the easiest may be to just
uninstall littler and rebuild it locally so that thew R 2.7.0 is used.
Ping me, or better still, the r-sig-debian list, with questions if you have
any. You need to subscribe to r-sig-debian before you can post there.
Lastly, if you only want or use R, use R :) 'r' is for scripting and short
command-line uses.
Dirk
PS It is the same with RPy.
| I found a bugreport here:
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686
| I'm not sure, if this has anything to do with it, as it concerns rkward...
|
| Anyway, this information might come handy:
| my system:
| ubuntu 7.10
| Kernel 2.6.22-14-generic
| GNOME 2.20.1
|
| installed packages:
| r-base 2.7.0-1gutsy0
| r-base-core 2.7.1gutsy0
| r-cran-cluster 1.11.10-1gutsy0
| r-cran-boot 1.2.32-1gutsy0
| r-cran-cluster 1.11.10-1gutsy0
| r-cran-codetools 0.2-0-1gutsy0
| r-cran-foreign 0.8.24-1gutsy0
| r-cran-kernsmooth 2.22.22-1gutsy0
| r-cran-lattice 0.17-6-1gutsy0
| r-cran-mgcv 1.3-30-1gutsy0
| r-cran-nlme 3.1.88-1gutsy0
| r-cran-rpart 3.1.41-1gutsy0
| r-cran-survival 2.34-1gutsy0
| r-cran-vr 7.2.41-1gutsy0
|
| rkward 0.4.7a-1ubuntu1
|
| r-recommended 2.7.0-1gutsy0
|
|
| I can't guarantee, that this list is complete, as I don't know (yet), how to
| check for it...
|
| Not really relevant, but I feel that I should tell you:
|
| The university at which I study used to use SPSS. Until this term, from which
on
| we will officially use r. Yeah!
|
| So, I hope you can help me getting r working. If I can help by doing anything,
| please tell me how...
| Also, I hope, this is a problem with r and not with my ubuntu, in which case I
| probably wouldn't have contacted you, if I would have known...
|
| Thank you very much!
|
| All the best,
| Jakob
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: (PR#11274)
On 24 April 2008 at 20:20, [EMAIL PROTECTED] wrote:
| Full_Name: Jakob Stoeger
| Version: 2.7.0
| OS: ubuntu 7.10
| Submission from: (NULL) (137.248.74.38)
|
|
| Hi!
|
| I hope, it is justified to write this email...
| I'm relatively new to linux, and haven't worked with r, yet, so please pardon
| any things I do not know...
|
| I tried installing r on my computer, and didn't manage to get the program
| running.
| After having installed littler, typing r into the bash results in following
| message:
|
| r: symbol lookup error: r: undefined symbol: R_Visible
You need to rebuild littler ('r') against the new version of R ('R').
I did that for Debian, looks like Ubuntu could do with it too. Your R
version was provided by volunteers outside of Ubuntu.
Vincent: In a perfect world, could you rebuild littler and provide it?
Jakob: Barring a new littler you can apt-get, the easiest may be to just
uninstall littler and rebuild it locally so that thew R 2.7.0 is used.
Ping me, or better still, the r-sig-debian list, with questions if you have
any. You need to subscribe to r-sig-debian before you can post there.
Lastly, if you only want or use R, use R :) 'r' is for scripting and short
command-line uses.
Dirk
PS It is the same with RPy.
| I found a bugreport here:
| http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686
| I'm not sure, if this has anything to do with it, as it concerns rkward...
|
| Anyway, this information might come handy:
| my system:
| ubuntu 7.10
| Kernel 2.6.22-14-generic
| GNOME 2.20.1
|
| installed packages:
| r-base 2.7.0-1gutsy0
| r-base-core 2.7.1gutsy0
| r-cran-cluster 1.11.10-1gutsy0
| r-cran-boot 1.2.32-1gutsy0
| r-cran-cluster 1.11.10-1gutsy0
| r-cran-codetools 0.2-0-1gutsy0
| r-cran-foreign 0.8.24-1gutsy0
| r-cran-kernsmooth 2.22.22-1gutsy0
| r-cran-lattice 0.17-6-1gutsy0
| r-cran-mgcv 1.3-30-1gutsy0
| r-cran-nlme 3.1.88-1gutsy0
| r-cran-rpart 3.1.41-1gutsy0
| r-cran-survival 2.34-1gutsy0
| r-cran-vr 7.2.41-1gutsy0
|
| rkward 0.4.7a-1ubuntu1
|
| r-recommended 2.7.0-1gutsy0
|
|
| I can't guarantee, that this list is complete, as I don't know (yet), how to
| check for it...
|
| Not really relevant, but I feel that I should tell you:
|
| The university at which I study used to use SPSS. Until this term, from which
on
| we will officially use r. Yeah!
|
| So, I hope you can help me getting r working. If I can help by doing anything,
| please tell me how...
| Also, I hope, this is a problem with r and not with my ubuntu, in which case I
| probably wouldn't have contacted you, if I would have known...
|
| Thank you very much!
|
| All the best,
| Jakob
|
| __
| R-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel
--
Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
Marc Schwartz wrote:
> Duncan Murdoch wrote:
>
>> Currently ?foo does help("foo"), which looks for a man page with alias
>> foo. If foo happens to be a function call, it will do a bit more, so
>>
>> ?mean(something)
>>
>> will find the mean method for something if mean happens to be an S4
>> generic. There are also the type?foo variations, e.g. methods?foo, or
>> package?foo.
>>
>> I think these are all too limited.
>>
>> The easiest search should be the most permissive. Users should need to
>> do extra work to limit their search to man pages, with exact matches, as
>> ? does.
>>
>> We don't currently have a general purpose search for "foo", or something
>> like it. We come close with RSiteSearch, and so possibly ?foo should
>> mean RSiteSearch("foo"), but
>> there are problems with that: it can't limit itself to the current
>> version of R, and it doesn't work when you're offline (or when
>> search.r-project.org is down.) We also have help.search("foo"), but it
>> is too limited. I'd like to have a local search that looks through the
>> man pages, manuals, FAQs, vignettes, DESCRIPTION files, etc., specific
>> to the current R installation, and I think ? should be attached to that
>> search.
>>
>> Comments, please.
>>
>> Duncan Murdoch
>>
>
> Duncan,
>
> I agree in principle with the points that you raise. I suspect that at
> least in part, it might assist new users with some of the issues that
> were raised in the latest incarnation of the 'we need better
> documentation' thread on r-help.
>
> I am not convinced that ?foo should do this however. help("foo")
> conceptually seems predicated upon the notion that a user is looking for
> a reference/help page for a specific function or descriptor called
> 'foo'. The user knows the name of the function or descriptor ...
With the current definition, that's correct, though man("foo") might be
a better match to Unix-users expectations for a function that did that.
For a naive user, help("foo") suggests that they're looking for help on
"foo".
>
> ... and should
> not have to wait for a search function to locate it or conceptually
> related terms. If the user has a large number of CRAN packages
> installed, such a search can take a rather long time. That's an issue
> for example with help.search().
>
As Brian and Hadley said, that's an implementation issue, already being
addressed.
> That being said and being a firm believer in incrementalism, perhaps the
> first step should be to create a new function, called esearch() [as in
> extended search] or doc.search() [as in documentation search] or even
> search.all(). This new function would facilitate searching all of the
> local objects that you list and perhaps others. It would by default be
> uber-inclusive of all categories of such objects. It would support
> functionality along the lines of help.search() in allowing for the use
> of regex and fuzzy matching via grep()/agrep().
>
Definitely there would need to be a new function, with a new name; if we
were attaching the name to ? somehow, then it wouldn't matter much what
name was used.
I haven't done it, but I suspect we could introduce special behaviour
for ??foo very easily. We could even have a whole hierarchy:
?foo, ??foo, ???foo, foo, ...
> The downside of this approach is that we would add yet another search
> function to the list of those already available, each of which searches
> a focused subset of the potential targets for assistance, whether local
> or online. Thus, it would require some level of understanding of the
> general structure of the myriad of local and online resources of R
> related assistance.
>
Part of the idea behind my suggestion is that it should be somewhat
automatic for a new user to learn about the different types of help.
One way for this to happen is the current one: expect them to find and
read the manuals. The suggestion is to make it easier to find the
different types. The risk of this is that exposing a new user to a wide
range of different kinds of results would just be confusing.
> Perhaps ?help could be augmented a bit in elucidating some of these
> issues. The See Also there does not reference apropos() for example and
> it might be worthwhile adding something along the lines of the bullets
> in the "Do your homework before posting" section in the Posting Guide.
> Thus ?help can become something of a "first place to look - local
> centralized help resource" for users to identify the tiered help
> resources that are available and to also provide a framework for how to
> use those resources. One could also have links to the online pages for R
> News, R Books, the R Wiki, the R Graph Gallery, Contributed
> Documentation, Bioconductor and Other Documentation, so that users
> become more aware of help resources beyond the documentation installed
> with R by default.
>
Those are probably good ideas, but my guess would be that
Re: [Rd] RFC: What should ?foo do?
Duncan Murdoch wrote: > I haven't done it, but I suspect we could introduce special behaviour > for ??foo very easily. We could even have a whole hierarchy: > > ?foo, ??foo, ???foo, foo, ... > > Heh, that's rather nice, actually. In words, that could read ?foo: tell me about foo! ??foo: what can you tell me about foo? ???foo: what can you tell me about things like foo? foo: I don't know what I'm looking for but it might be something related foo? You do have to be careful about messing with ?, though. I think many people, including me, would pretty quickly go nuts if ?par suddenly didn't work the way we're used to. -- 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 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
Duncan Murdoch wrote:
> Currently ?foo does help("foo"), which looks for a man page with alias
> foo. If foo happens to be a function call, it will do a bit more, so
>
> ?mean(something)
>
> will find the mean method for something if mean happens to be an S4
> generic. There are also the type?foo variations, e.g. methods?foo, or
> package?foo.
>
> I think these are all too limited.
>
> The easiest search should be the most permissive. Users should need to
> do extra work to limit their search to man pages, with exact matches, as
> ? does.
While I like the idea, I don't really agree with the sentiment above.
I think that the easiest search should be the one that you want the
result of most often.
And at least for me that is the man page for the function, so I can
check some detail; and it works pretty well. I use site searches much
less frequently and would be happy to type more for them.
>
> We don't currently have a general purpose search for "foo", or something
> like it. We come close with RSiteSearch, and so possibly ?foo should
> mean RSiteSearch("foo"), but
> there are problems with that: it can't limit itself to the current
> version of R, and it doesn't work when you're offline (or when
> search.r-project.org is down.) We also have help.search("foo"), but it
> is too limited. I'd like to have a local search that looks through the
> man pages, manuals, FAQs, vignettes, DESCRIPTION files, etc., specific
> to the current R installation, and I think ? should be attached to that
> search.
I think that would be very useful (although there will be some
decisions on which tool to use to achieve this). But, it will also be
problematic, as one will get tons of hits for some things, and then
selecting the one you really want will be a pain.
I would rather see that be one of the dyadic forms, say
site?foo
or
all?foo
one could even imagine refining that for different subsets of the docs
you have mentioned;
help?foo #only man pages
guides?foo #the manuals, R Extensions etc
and so on.
You did not, make a suggestion as to how we would get the equivalent
of ?foo now, if a decision to move were taken.
>
> Comments, please.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
> > But that's just a problem with the current implementation. Better > > indexing could make full text search of all documentation practical > > instantaneous. This is one argument for a centralised documentation > > web site - such indices are much easier to set up in a modern web > > development environment. I could imagine this being an eventual > > feature of crantastic.org, but it requires on some tool to turn Rd > > files into a form more easily parsed with off-the-shelf tools (ideally > > xml). > > > > The search is a lot faster in 2.7.x, but is limited by disc speed (and > hence is relatively slow on Windows -- and I have a box which has both Linux > and Windows on, so I've tested this on identical hardware). R is a dynamic > environment which can change libraries (and their order), add or remove > packages The text search is pretty close to instantaneous (try it a > second time) -- the time is taken building the database for the first use. Would it be possible to build per package help databases during the install (or build?) process? That way all that work could be shifted to one a one off compilation. > Yes, we could do this differently, but some credit for the work already > done would be an encouragement to continue to improve. Sorry! Writing a good text search engine is hard and I didn't mean to disparage the existing work of R-core. The current system works great for the majority of uses. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On Fri, Apr 25, 2008 at 7:46 AM, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > Duncan Murdoch wrote: > > I haven't done it, but I suspect we could introduce special behaviour > > for ??foo very easily. We could even have a whole hierarchy: > > > > ?foo, ??foo, ???foo, foo, ... > > > > > Heh, that's rather nice, actually. In words, that could read > > ?foo: tell me about foo! > ??foo: what can you tell me about foo? > ???foo: what can you tell me about things like foo? > foo: I don't know what I'm looking for but it might be something > related foo? I like the idea, but why do not it automatically and then display the results on a single page? (i.e. list results in order of specificity) Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
> I would rather see that be one of the dyadic forms, say > >site?foo > > or >all?foo I'd be interested to know how many R users are aware of the dyadic form - I suspect it's very very few. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On Apr 25, 2008, at 8:46 AM, Peter Dalgaard wrote: > Duncan Murdoch wrote: >> I haven't done it, but I suspect we could introduce special behaviour >> for ??foo very easily. We could even have a whole hierarchy: >> >> ?foo, ??foo, ???foo, foo, ... >> >> > Heh, that's rather nice, actually. In words, that could read > > ?foo: tell me about foo! > ??foo: what can you tell me about foo? > ???foo: what can you tell me about things like foo? > foo: I don't know what I'm looking for but it might be something > related foo? > > You do have to be careful about messing with ?, though. I think many > people, including me, would pretty quickly go nuts if ?par suddenly > didn't work the way we're used to. > I strongly agree with that. One potential way out could be to offer some extended fall-back in case the man page doesn't exist. (I'm not sure I like that, either, but I could get used to it ;).) I don't really have a problem with status quo and I think if you want proper advanced searches, you should be using (or implementing them) in the GUIs anyway. That is what the new users will be using (and looking for) in the first place. If they have to count the question marks instead, they won't know about it (although I like the idea for advanced users). Cheers, Simon > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On 4/25/2008 10:16 AM, Robert Gentleman wrote:
>
> Duncan Murdoch wrote:
>> Currently ?foo does help("foo"), which looks for a man page with alias
>> foo. If foo happens to be a function call, it will do a bit more, so
>>
>> ?mean(something)
>>
>> will find the mean method for something if mean happens to be an S4
>> generic. There are also the type?foo variations, e.g. methods?foo, or
>> package?foo.
>>
>> I think these are all too limited.
>>
>> The easiest search should be the most permissive. Users should need to
>> do extra work to limit their search to man pages, with exact matches, as
>> ? does.
>
>While I like the idea, I don't really agree with the sentiment above.
> I think that the easiest search should be the one that you want the
> result of most often.
> And at least for me that is the man page for the function, so I can
> check some detail; and it works pretty well. I use site searches much
> less frequently and would be happy to type more for them.
That's true.
What's your feeling about what should happen when ?foo fails?
>
>>
>> We don't currently have a general purpose search for "foo", or something
>> like it. We come close with RSiteSearch, and so possibly ?foo should
>> mean RSiteSearch("foo"), but
>> there are problems with that: it can't limit itself to the current
>> version of R, and it doesn't work when you're offline (or when
>> search.r-project.org is down.) We also have help.search("foo"), but it
>> is too limited. I'd like to have a local search that looks through the
>> man pages, manuals, FAQs, vignettes, DESCRIPTION files, etc., specific
>> to the current R installation, and I think ? should be attached to that
>> search.
>
> I think that would be very useful (although there will be some
> decisions on which tool to use to achieve this). But, it will also be
> problematic, as one will get tons of hits for some things, and then
> selecting the one you really want will be a pain.
>
> I would rather see that be one of the dyadic forms, say
>
>site?foo
>
> or
>all?foo
>
> one could even imagine refining that for different subsets of the docs
> you have mentioned;
>
>help?foo #only man pages
>guides?foo #the manuals, R Extensions etc
>
> and so on.
>
>You did not, make a suggestion as to how we would get the equivalent
> of ?foo now, if a decision to move were taken.
I didn't say, but I would assume there would be a way to do it, and it
shouldn't be hard to invoke. Maybe help?foo as you suggested, or man?foo.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On 4/25/2008 10:18 AM, hadley wickham wrote: > On Fri, Apr 25, 2008 at 7:46 AM, Peter Dalgaard > <[EMAIL PROTECTED]> wrote: >> Duncan Murdoch wrote: >> > I haven't done it, but I suspect we could introduce special behaviour >> > for ??foo very easily. We could even have a whole hierarchy: >> > >> > ?foo, ??foo, ???foo, foo, ... >> > >> > >> Heh, that's rather nice, actually. In words, that could read >> >> ?foo: tell me about foo! >> ??foo: what can you tell me about foo? >> ???foo: what can you tell me about things like foo? >> foo: I don't know what I'm looking for but it might be something >> related foo? > > I like the idea, but why do not it automatically and then display the > results on a single page? (i.e. list results in order of specificity) One reason not to do that is that in single-threaded R you are pretty much stuck until it is done. Presumably the more specific search is quicker than the less specific one. And even if we could act on results as soon as they were available, I think a lot of users would wait for the search to stop, so there'd be a perception that it was too slow. One possible change to ?foo that would not be so painful for old-time users would be to try it under its current meaning first, and only fall back to a more general search if that fails. Consistent with this idea would be something like the "I feel lucky" search on Google, i.e. ?foo would go immediately to the best match, while ??foo would present a list of possible matches. This is not consistent with current behaviour, where ?foo will present a list if it matches two or more topics, but I think we can always rank one ahead of the other based on their ordering in the search list. I don't know if it will be so easy to rank hits coming from help.search(), or from other searches that don't exist yet: but maybe it doesn't matter. If someone doesn't like what they get from ?foo, they can always try ??foo. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
> Consistent with this idea would be something like the "I feel lucky" search > on Google, i.e. ?foo would go immediately to the best match, while ??foo > would present a list of possible matches. This is not consistent with > current behaviour, where ?foo will present a list if it matches two or more > topics, but I think we can always rank one ahead of the other based on their > ordering in the search list. I don't know if it will be so easy to rank > hits coming from help.search(), or from other searches that don't exist yet: > but maybe it doesn't matter. If someone doesn't like what they get from > ?foo, they can always try ??foo. That seems like a good compromise to me - it's a metaphor familiar to most people, and corresponds roughly to the current behaviour of help and help.search. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On 4/25/2008 10:41 AM, Simon Urbanek wrote: > On Apr 25, 2008, at 8:46 AM, Peter Dalgaard wrote: > >> Duncan Murdoch wrote: >>> I haven't done it, but I suspect we could introduce special behaviour >>> for ??foo very easily. We could even have a whole hierarchy: >>> >>> ?foo, ??foo, ???foo, foo, ... >>> >>> >> Heh, that's rather nice, actually. In words, that could read >> >> ?foo: tell me about foo! >> ??foo: what can you tell me about foo? >> ???foo: what can you tell me about things like foo? >> foo: I don't know what I'm looking for but it might be something >> related foo? >> >> You do have to be careful about messing with ?, though. I think many >> people, including me, would pretty quickly go nuts if ?par suddenly >> didn't work the way we're used to. >> > > I strongly agree with that. > > One potential way out could be to offer some extended fall-back in > case the man page doesn't exist. (I'm not sure I like that, either, > but I could get used to it ;).) > > I don't really have a problem with status quo and I think if you want > proper advanced searches, you should be using (or implementing them) > in the GUIs anyway. That is what the new users will be using (and > looking for) in the first place. If they have to count the question > marks instead, they won't know about it (although I like the idea for > advanced users). I'd like to try to have the search common across all platforms, but the GUIs could present it and the results in their own way. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
Duncan Murdoch wrote:
> Marc Schwartz wrote:
>> Duncan Murdoch wrote:
>>
>>> Currently ?foo does help("foo"), which looks for a man page with
>>> alias foo. If foo happens to be a function call, it will do a bit
>>> more, so
>>>
>>> ?mean(something)
>>>
>>> will find the mean method for something if mean happens to be an S4
>>> generic. There are also the type?foo variations, e.g. methods?foo,
>>> or package?foo.
>>>
>>> I think these are all too limited.
>>>
>>> The easiest search should be the most permissive. Users should need
>>> to do extra work to limit their search to man pages, with exact
>>> matches, as ? does.
>>>
>>> We don't currently have a general purpose search for "foo", or
>>> something like it. We come close with RSiteSearch, and so possibly
>>> ?foo should mean RSiteSearch("foo"), but
>>> there are problems with that: it can't limit itself to the current
>>> version of R, and it doesn't work when you're offline (or when
>>> search.r-project.org is down.) We also have help.search("foo"), but
>>> it is too limited. I'd like to have a local search that looks through
>>> the man pages, manuals, FAQs, vignettes, DESCRIPTION files, etc.,
>>> specific to the current R installation, and I think ? should be
>>> attached to that search.
>>>
>>> Comments, please.
>>>
>>> Duncan Murdoch
>>>
>>
>> Duncan,
>>
>> I agree in principle with the points that you raise. I suspect that at
>> least in part, it might assist new users with some of the issues that
>> were raised in the latest incarnation of the 'we need better
>> documentation' thread on r-help.
>>
>> I am not convinced that ?foo should do this however. help("foo")
>> conceptually seems predicated upon the notion that a user is looking
>> for a reference/help page for a specific function or descriptor called
>> 'foo'. The user knows the name of the function or descriptor ...
>
> With the current definition, that's correct, though man("foo") might be
> a better match to Unix-users expectations for a function that did that.
> For a naive user, help("foo") suggests that they're looking for help on
> "foo".
I agree that man("foo") would be consistent with looking for help with a
known specific function. I also agree that Linux/Unix users would expect
such behavior. However, I am not sure that Windows users would be so
inclined. Certainly as a former Windows user and despite many years of
programming experience in various environments, I would not, out of the
gate, have instinctively known or thought about man("foo").
That is not to argue against moving in that direction however. In fact,
as part of any future consolidation of the myriad help and search
functions, it would make a great deal of sense that ?foo become an alias
for man("foo") rather than help("foo").
Thus, the other help/search related functions could also consolidate
around a mechanism with two key distinctions, that being local versus
online sources.
>> ... and should not have to wait for a search function to locate it or
>> conceptually related terms. If the user has a large number of CRAN
>> packages installed, such a search can take a rather long time. That's
>> an issue for example with help.search().
>>
>
> As Brian and Hadley said, that's an implementation issue, already being
> addressed.
My comment there was more of an observation rather than a criticism and
my apologies if it was taken as the latter. I think it is reasonable to
expect, that if a useR has 1,300+ CRAN packages installed, that it is
going to take longer to search that infrastructure, than if the useR
only has a few.
I would want to have a reasonable expectation however, that if I used
?t.test as opposed to help.search("t test"), the result would be
forthcoming in a more efficient manner in the former case than in the
latter. In the former case, I am typically looking for a specific
function in a package that is in the search path. In the latter, I am
searching for related terms/concepts in all installed packages, etc.
>> That being said and being a firm believer in incrementalism, perhaps
>> the first step should be to create a new function, called esearch()
>> [as in extended search] or doc.search() [as in documentation search]
>> or even search.all(). This new function would facilitate searching all
>> of the local objects that you list and perhaps others. It would by
>> default be uber-inclusive of all categories of such objects. It would
>> support functionality along the lines of help.search() in allowing for
>> the use of regex and fuzzy matching via grep()/agrep().
>>
>
> Definitely there would need to be a new function, with a new name; if we
> were attaching the name to ? somehow, then it wouldn't matter much what
> name was used.
>
> I haven't done it, but I suspect we could introduce special behaviour
> for ??foo very easily. We could even have a whole hierarchy:
>
> ?foo, ??foo, ???foo, foo, ...
Conceptuall
Re: [Rd] RFC: What should ?foo do?
> It seems logical to me that such a resource be embedded up front in "Intro" > with it also being included within the existing help system and referenced > in the start up banner message. That would help if anyone actually read the startup banner. The next time you're in front of an audience of people who have been using R for a couple of weeks, ask them how to cite R. Hadley -- http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
Duncan Murdoch wrote:
> On 4/25/2008 10:16 AM, Robert Gentleman wrote:
>>
>> Duncan Murdoch wrote:
>>> Currently ?foo does help("foo"), which looks for a man page with
>>> alias foo. If foo happens to be a function call, it will do a bit
>>> more, so
>>>
>>> ?mean(something)
>>>
>>> will find the mean method for something if mean happens to be an S4
>>> generic. There are also the type?foo variations, e.g. methods?foo,
>>> or package?foo.
>>>
>>> I think these are all too limited.
>>>
>>> The easiest search should be the most permissive. Users should need
>>> to do extra work to limit their search to man pages, with exact
>>> matches, as ? does.
>>
>>While I like the idea, I don't really agree with the sentiment
>> above. I think that the easiest search should be the one that you want
>> the result of most often.
>> And at least for me that is the man page for the function, so I can
>> check some detail; and it works pretty well. I use site searches much
>> less frequently and would be happy to type more for them.
>
> That's true.
>
> What's your feeling about what should happen when ?foo fails?
present of list of man pages with spellings close to foo (we have the
tools to do this in many places right now, and it would be a great help,
IMHO, as spellings and capitalization behavior varies both between and
within individuals), so the user can select one
>
>
>>
>>>
>>> We don't currently have a general purpose search for "foo", or
>>> something like it. We come close with RSiteSearch, and so possibly
>>> ?foo should mean RSiteSearch("foo"), but
>>> there are problems with that: it can't limit itself to the current
>>> version of R, and it doesn't work when you're offline (or when
>>> search.r-project.org is down.) We also have help.search("foo"), but
>>> it is too limited. I'd like to have a local search that looks through
>>> the man pages, manuals, FAQs, vignettes, DESCRIPTION files, etc.,
>>> specific to the current R installation, and I think ? should be
>>> attached to that search.
>>
>> I think that would be very useful (although there will be some
>> decisions on which tool to use to achieve this). But, it will also be
>> problematic, as one will get tons of hits for some things, and then
>> selecting the one you really want will be a pain.
>>
>> I would rather see that be one of the dyadic forms, say
>>
>>site?foo
>>
>> or
>>all?foo
>>
>> one could even imagine refining that for different subsets of the
>> docs you have mentioned;
>>
>>help?foo #only man pages
>>guides?foo #the manuals, R Extensions etc
>>
>> and so on.
>>
>>You did not, make a suggestion as to how we would get the
>> equivalent of ?foo now, if a decision to move were taken.
>
> I didn't say, but I would assume there would be a way to do it, and it
> shouldn't be hard to invoke. Maybe help?foo as you suggested, or man?foo.
If not then I would be strongly opposed -- I really think we want to
make the most common thing the easiest to do. And if we really think
that might be different for different people, then disambiguate the
"short-cut", ? in this case, from the command so that users have some
freedom to customize, would be my favored alternative.
I also wonder if one could not also provide some mechanism to provide
distinct information on what is local vs what is on the internet.
Something that would make tools like spotlight much more valuable, IMHO,
is to tell me what I have on my computer, and what I can get, if I want
to; at least as some form of option.
Robert
>
> Duncan Murdoch
>
--
Robert Gentleman, PhD
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M2-B876
PO Box 19024
Seattle, Washington 98109-1024
206-667-7700
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
hadley wickham wrote:
>> It seems logical to me that such a resource be embedded up front in "Intro"
>> with it also being included within the existing help system and referenced
>> in the start up banner message.
>
> That would help if anyone actually read the startup banner. The next
> time you're in front of an audience of people who have been using R
> for a couple of weeks, ask them how to cite R.
>
> Hadley
That might be supportive of having the startup banner be nothing more
than a version/copyright notice and then leave you at a '>" prompt.
I am open to the notion however, that some do read it, perhaps less so
over time as they just want to get to the prompt and effectively become
oblivious to the banner.
Of course, it ('citation()') is also referenced in the main R FAQ...
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
For what it's worth, I use ?foo mostly to look up usage of functions
that I know I want to use, and find it perfect for that (one benefit
over help() is that completion works for ?). The only thing I miss is
the ability to do the equivalent of help("foo", package = "bar");
?bar::foo gives the help page for "::". Perhaps that would be
something to consider for addition.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
Dear all,
Why not leave ? more-or-less as it is (at least for ?foo) and add arguments
to help() for other kinds of searches? Perhaps the kind of search that
help() does by default could be set as an option.
Regards,
John
--
John Fox, Professor
Department of Sociology
McMaster University
Hamilton, Ontario, Canada
web: socserv.mcmaster.ca/jfox
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> project.org] On Behalf Of Deepayan Sarkar
> Sent: April-25-08 1:54 PM
> To: R-devel
> Subject: Re: [Rd] RFC: What should ?foo do?
>
> For what it's worth, I use ?foo mostly to look up usage of functions
> that I know I want to use, and find it perfect for that (one benefit
> over help() is that completion works for ?). The only thing I miss is
> the ability to do the equivalent of help("foo", package = "bar");
> ?bar::foo gives the help page for "::". Perhaps that would be
> something to consider for addition.
>
> -Deepayan
>
> __
> 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] RFC: What should ?foo do?
On Fri, 25 Apr 2008, Deepayan Sarkar wrote:
> For what it's worth, I use ?foo mostly to look up usage of functions
> that I know I want to use, and find it perfect for that (one benefit
> over help() is that completion works for ?). The only thing I miss is
> the ability to do the equivalent of help("foo", package = "bar");
> ?bar::foo gives the help page for "::". Perhaps that would be
> something to consider for addition.
That fits most naturally with the (somewhat technical) idea that bar::foo
becomes a symbol and not a function call. I believe that several of think
that is in principle a better idea, but no one has as yet (AFAIK) explored
the ramifications.
However, 5 mins looking at the sources suggests that it is easy to do.
--
Brian D. Ripley, [EMAIL PROTECTED]
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
Re: [Rd] r won't start: "r: symbol lookup error: r: undefined symbol: R_Visible" (PR#11265)
Le ven. 25 avr. à 07:09, Dirk Eddelbuettel a écrit :
>
> On 24 April 2008 at 20:20, [EMAIL PROTECTED] wrote:
> | Full_Name: Jakob Stoeger
> | Version: 2.7.0
> | OS: ubuntu 7.10
> | Submission from: (NULL) (137.248.74.38)
> |
> |
> | Hi!
> |
> | I hope, it is justified to write this email...
> | I'm relatively new to linux, and haven't worked with r, yet, so
> please pardon
> | any things I do not know...
> |
> | I tried installing r on my computer, and didn't manage to get the
> program
> | running.
> | After having installed littler, typing r into the bash results in
> following
> | message:
> |
> | r: symbol lookup error: r: undefined symbol: R_Visible
>
> You need to rebuild littler ('r') against the new version of R ('R').
>
> I did that for Debian, looks like Ubuntu could do with it too. Your R
> version was provided by volunteers outside of Ubuntu.
>
> Vincent: In a perfect world, could you rebuild littler and provide it?
I'm not convinced this was the problem (probably more the case issue
raised by others), but heck, it was simple to build packages for
littler. On their way to CRAN now.
*However*, I won't commit to always maintain this package for Ubuntu.
Our general policy is to provide up-to-date binaries for the
Recommended packages only.
HTH Vincent
>
>
> Jakob: Barring a new littler you can apt-get, the easiest may be to
> just
> uninstall littler and rebuild it locally so that thew R 2.7.0 is used.
> Ping me, or better still, the r-sig-debian list, with questions if
> you have
> any. You need to subscribe to r-sig-debian before you can post there.
>
> Lastly, if you only want or use R, use R :) 'r' is for scripting
> and short
> command-line uses.
>
> Dirk
>
> PS It is the same with RPy.
>
> | I found a bugreport here:
> | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=418686
> | I'm not sure, if this has anything to do with it, as it concerns
> rkward...
> |
> | Anyway, this information might come handy:
> | my system:
> | ubuntu 7.10
> | Kernel 2.6.22-14-generic
> | GNOME 2.20.1
> |
> | installed packages:
> | r-base 2.7.0-1gutsy0
> | r-base-core 2.7.1gutsy0
> | r-cran-cluster 1.11.10-1gutsy0
> | r-cran-boot 1.2.32-1gutsy0
> | r-cran-cluster 1.11.10-1gutsy0
> | r-cran-codetools 0.2-0-1gutsy0
> | r-cran-foreign 0.8.24-1gutsy0
> | r-cran-kernsmooth 2.22.22-1gutsy0
> | r-cran-lattice 0.17-6-1gutsy0
> | r-cran-mgcv 1.3-30-1gutsy0
> | r-cran-nlme 3.1.88-1gutsy0
> | r-cran-rpart 3.1.41-1gutsy0
> | r-cran-survival 2.34-1gutsy0
> | r-cran-vr 7.2.41-1gutsy0
> |
> | rkward 0.4.7a-1ubuntu1
> |
> | r-recommended 2.7.0-1gutsy0
> |
> |
> | I can't guarantee, that this list is complete, as I don't know
> (yet), how to
> | check for it...
> |
> | Not really relevant, but I feel that I should tell you:
> |
> | The university at which I study used to use SPSS. Until this term,
> from which on
> | we will officially use r. Yeah!
> |
> | So, I hope you can help me getting r working. If I can help by
> doing anything,
> | please tell me how...
> | Also, I hope, this is a problem with r and not with my ubuntu, in
> which case I
> | probably wouldn't have contacted you, if I would have known...
> |
> | Thank you very much!
> |
> | All the best,
> | Jakob
> |
> | __
> | R-devel@r-project.org mailing list
> | https://stat.ethz.ch/mailman/listinfo/r-devel
>
> --
> Three out of two people have difficulties with fractions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] returning vectors of unknown size from C (with .C)
Dear All, In a package, I am using ".C" to call some C functions. In one case, the number of elements of the return vectors are not known in R before the C call. (Two of the vectors are integers, the third is vector of character strings). Passing from R a vector of the maximum possible size would be a huge waste. I understand one alternative is to use ".Call", but I'd rather avoid it if I can (all of the code seems working except for the return of values into R). Another would be to write to a file from C and then read that into R, but this looks very ugly. Are there any other reasonable alternatives, or should I just use .Call? Thanks, R. -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] returning vectors of unknown size from C (with .C)
Ramon Diaz-Uriarte wrote: > Dear All, > > In a package, I am using ".C" to call some C functions. In one case, > the number of elements of the return vectors are not known in R before > the C call. (Two of the vectors are integers, the third is vector of > character strings). > > Passing from R a vector of the maximum possible size would be a huge > waste. I understand one alternative is to use ".Call", but I'd rather > avoid it if I can (all of the code seems working except for the return > of values into R). Another would be to write to a file from C and then > read that into R, but this looks very ugly. Are there any other > reasonable alternatives, or should I just use .Call? > .Call is usually easiest, but another possibility is to have two entry points: one to calculate how much space you need, a second to pass in a vector that's the right size to hold the result. Duncan Murdoch > Thanks, > > R. > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] remarks on function pnbeta (PR#11277)
Dear Developers, The pnbeta function has been reviewed recently in the article of A. Baharev, S. Kem=E9ny, On the computation of the noncentral F and noncentral beta distribution, Statistics and Computing, 2008, in press. Preprint of the paper is available here: http://reliablecomputing.eu/publications.html and the article here http://dx.doi.org/10.1007/s11222-008-9061-3 I suggest increasing the itrmax to (at least) 2000, since practically important values cannot be computed with the current value. For example: pnbeta(0.2057, 25.0, 0.5, 34012.98, 1, 0); needs 1649 iterations on my machine, and returns 0.0752037 instead of the true value 0.10. This is not a bug, i got a warning, however i think it would be better to increase the iteration limit. According to my experience the users tend to ignore warning messages and would use the incorrect values that is why i think it would be better if pnbeta called exit(EXIT_FAILURE) or throw an exception than returning a completely incorrect value and let the user use that. This is my personal opinion, i do not know more about the design and application logic of R. The source file pnbeta.c refers to the paper of Frick (1990, AS R84) giving a FORTRAN implementation. That paper contains typos; those were corrected by Lam (1995, AS R95). Lam also made some remarks that are worth considering. The R implementation is a revised C code, and it seems to me that the pnbeta's implementation is not influenced by the typos in the paper of Frick. However it would be better to indicate that the pnbeta is a revised implementation compared to AS 226 and AS R84, and is not influenced by AS R95. Cancellation may occur during the recursion in the do while loop, we failed to produce an example using practically meaningful parameter values where serious cancellation occurs. We suspect it may be an issue where the corresponding probability is small (less then 1.0E-30). We plan to contribute a C implementation of our algorithm where cancellation cannot occur, and newton iteration for the noncentrality parameter is included. The computation of the noncentrality parameter is need for ANOVA purposes. Best regards, Ali Baharev __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in R 2.7 for over long lines (crasher+proposed fix!) (PR#11281)
OK, I am just sending it here too as it looks like r-devel@r-project.org
is not the right place:
=EF=BB=BFOn Fri, 2008-04-25 at 08:48 +0200, Soeren Sonnenburg wrote:
> While trying to fix swig & R2.7 I actually discovered that there is a
> bug in R 2.7 causing a crash (so R & swig might actually work):
>=20
> the bug is in ./src/main/gram.c line 3038:
>=20
> } else { /* over-long line */
> fixthis --> char *LongLine =3D (char *) malloc(nc);
> if(!LongLine)
> error(_("unable to allocate space for source line %
d"), xxlineno);
> strncpy(LongLine, (char *)p0, nc);
> bug -->LongLine[nc] =3D '\0';
> SET_STRING_ELT(source, lines++,
>mkChar2((char *)LongLine));
> free(LongLine);
>=20
> note that LongLine is only nc chars long, so the LongLine[nc]=3D'\0'
might
> be an out of bounds write. the fix would be to do
>=20
> =EF=BB=BFchar *LongLine =3D (char *) malloc(nc+1);
>=20
> in line 3034
>=20
> Please fix and thanks to dirk for the debian r-base-dbg package!
Looking at the code again there seems to be another bug above this for
the MAXLINESIZE test too:
if (*p =3D=3D '\n' || p =3D=3D end - 1) {
nc =3D p - p0;
if (*p !=3D '\n')
nc++;
if (nc <=3D MAXLINESIZE) {
strncpy((char *)SourceLine, (char *)p0, nc);
bug2 -->SourceLine[nc] =3D '\0';
SET_STRING_ELT(source, lines++,
mkChar2((char *)SourceLine));
} else { /* over-long line */
char *LongLine =3D (char *) malloc(nc+1);
if(!LongLine)
error(_("unable to allocate space for source line %d"),
xxlineno);
bug1 -->strncpy(LongLine, (char *)p0, nc);
LongLine[nc] =3D '\0';
SET_STRING_ELT(source, lines++,
mkChar2((char *)LongLine));
free(LongLine);
}
p0 =3D p + 1;
}
So I guess the test would be for nc < MAXLINESIZE above or to change
SourceLine to have MAXLINESIZE+1 size.
Alternatively as the strncpy manpage suggests do this for all
occurrences of strncpy
strncpy(buf, str, n);
if (n > 0)
buf[n - 1]=3D =E2=80=99\0=E2=80=99;
this could even be made a makro / helper function ...
And another update: This does fix the R+swig crasher for me (tested)!
Soeren
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
