[Rd] Alpha and Beta testing of R versions
[Mainly for R-foundation members; but kept in public for general
brainstorming...]
> "Simon" == Simon Urbanek <[EMAIL PROTECTED]>
> on Thu, 3 Nov 2005 12:16:25 -0500 writes:
<>
Simon> As Brian was saying, the error was fixed in R
Simon> immediately after the release - strangely enough no
Simon> one reported the error during the alpha and beta
Simon> cycle although both the GUI and R binaries were
Simon> available for download :(.
Unfortunately, the phrase "strangely enough" could be replaced with
``as almost always''.
Maybe we (the R-foundation) should give serious thoughts to
offer prizes for valid bug reports during alpha and beta
testing. These could include
- Reduced fee for 'useR' and 'DSC' conferences
- being listed as helpful person in R's 'THANKS' file
{but that may not entice those who are already listed},
or even in the NEWS of the new relase
or on the "Hall of fame of R beta testers"
In order to discourage an increased number of non-bug reports we
may have to also open a "hall of shame" though...
Martin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Alpha and Beta testing of R versions
[...]
> Maybe we (the R-foundation) should give serious thoughts to
> offer prizes for valid bug reports during alpha and beta
> testing. These could include
> - Reduced fee for 'useR' and 'DSC' conferences
> - being listed as helpful person in R's 'THANKS' file
> {but that may not entice those who are already listed},
> or even in the NEWS of the new relase
> or on the "Hall of fame of R beta testers"
... formalized as a bug finding contest, for example?
-d
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Alpha and Beta testing of R versions
Martin's point is generally very valid, but in the case of the 2.2.0
release remarkably few of the bugs found since release were new in 2.2.0.
One thing we have learnt is that none of the testers seem to look at HTML
help (which accounts for 2 of the 4 2.2.0-only bugs I counted).
What we need most is persistent help in testing each release, especially
on unusual platforms. How do we `incentivize' that?
On Fri, 4 Nov 2005, Martin Maechler wrote:
> [Mainly for R-foundation members; but kept in public for general
> brainstorming...]
>
>> "Simon" == Simon Urbanek <[EMAIL PROTECTED]>
>> on Thu, 3 Nov 2005 12:16:25 -0500 writes:
>
> <>
>
>Simon> As Brian was saying, the error was fixed in R
>Simon> immediately after the release - strangely enough no
>Simon> one reported the error during the alpha and beta
>Simon> cycle although both the GUI and R binaries were
>Simon> available for download :(.
>
> Unfortunately, the phrase "strangely enough" could be replaced with
> ``as almost always''.
>
> Maybe we (the R-foundation) should give serious thoughts to
> offer prizes for valid bug reports during alpha and beta
> testing. These could include
> - Reduced fee for 'useR' and 'DSC' conferences
> - being listed as helpful person in R's 'THANKS' file
> {but that may not entice those who are already listed},
> or even in the NEWS of the new relase
> or on the "Hall of fame of R beta testers"
>
> In order to discourage an increased number of non-bug reports we
> may have to also open a "hall of shame" though...
>
> Martin
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
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] shared-mime-info (PR#8278)
[EMAIL PROTECTED] writes: > Hi, > > On 03 Nov 2005 12:41:53 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wr= > ote: > > [EMAIL PROTECTED] writes: > > > > > We do not usually put features in R which are specific to just some > > > distributions of some OSes, and in this case to one editor on those. > > > We do not for example include the ESS mode for the much-more-widely-use= > d > > > Emacs family of editors. > > > > > > This looks as if it might be appropriate to the Linux binary packages f= > or > > > R, so I suggest you contact their maintainers. But my understanding is > > > that this is an issue for gedit and not for R. Indeed .R is just a > > > convention (one of many choices, including .r and .q) for R itself. > > > > > > I do wonder why you concentrated on .R files and not .Rd files, where I > > > find syntax highlighting more useful. > > > > Mime-types shouldn't be distribution-specific or even editor-specific, > > should they? The whole point is that they can be used for things like > > email attachments that pass from one OS to the other. > > > > It might be useful to have the mime-type definitions for R (and Rd) > > files centralized in R core, with the appropriate OS conventions > > systematized. But I think we need to know more. Who keeps track of > > mime-types? Can we just grab text/x-R (and text/x-Rd and > > application/x-Rdata)? To which extent the XML format a standard; is it > > only used by particular applications? > > > > > As far as I know, at least in Debian, the mimetypes are tracked by > shared-mime-info package. The upstream is freedesktop.org. I do not > know about oficial standarts, but Gnome and KDE tries to adher to some > of the freedesktop.org standarts. I can confirm that mimetypes > provided by shared-mime-info are widely used in Gnome, for some time > now. One further thought about this: On SUSE, rpm -qif /usr/share/mime/ points at http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo So I guess that the proper tree to bark at is the upstreams maintainers of http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz Instructions there say to submit new XML files to https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED It would likely be a good idea to send them first to R-devel for review. -- 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] shared-mime-info (PR#8278)
Hi, On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > One further thought about this: > > On SUSE, > > rpm -qif /usr/share/mime/ > > points at > > http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo > > So I guess that the proper tree to bark at is the upstreams > maintainers of > > http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz > > Instructions there say to submit new XML files to > > https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > It would likely be a good idea to send them first to R-devel for review. > I already barked at upstream. The upstream barked back. The result is here: https://bugs.freedesktop.org/show_bug.cgi?id=1782 There you can find xml file for R scripts. I've made it from some example. It is really only a proof of a concept. But it would not be very difficult to produce xml files for mimetypes of all R related files. We must only decide which R related files would benefit from having mimetypes. My proposal is 1. R source code, R scripts. Files with extensions .R, .r and others (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc 2. R documentation files. File extension .Rd. Mimetype text/x-Rd 3. RData files. File extension .RData, files which at beginning have RDX2. Mimetype application/x-RData. 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype text/x-Rtranscript The relevant xml code could be pushed upstream to end up in freedesktop.org.xml, or it could be distributed with R linux package, and installed into relevant subdirectory of /usr/share/mime. With a bit more work the result could be, that people using for example Nautilus (graphical Gnome browser) could see R related files displayed with R logo, and clicking them could result in various appropriate actions. For example for .RData R process could be iinvoked and relevant .RData file could be loaded. I could write and test the xml code. But first we have to agree on which files benefit from having mimetypes and how the mimetypes should be named. Feel free to suggest. Vaidotas Zemlys -- Doctorate student, http://www.mif.vu.lt/katedros/eka/katedra/zemlys.php Vilnius University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Alpha and Beta testing of R versions
On Nov 4, 2005, at 6:58 AM, Prof Brian Ripley wrote:
> Martin's point is generally very valid, but in the case of the
> 2.2.0 release remarkably few of the bugs found since release were
> new in 2.2.0.
> One thing we have learnt is that none of the testers seem to look
> at HTML help (which accounts for 2 of the 4 2.2.0-only bugs I
> counted).
>
> What we need most is persistent help in testing each release,
> especially on unusual platforms. How do we `incentivize' that?
I suspect that in the particular case of OS X the problem was
probably visibility - it was the first time ever that nightly OS X
binaries were available during alpha/beta phase (afaict), but I'm not
sure how many people knew about it. I think posted about it on R-SIG-
Mac during some discussion, but maybe I should have announced it more
specifically somewhere. I'm, not even sure whether there was a link
from the main page on CRAN. I would think that OS X users are more
likely to rely on binaries, so the above is more relevant than on
other platforms.
>> - being listed as helpful person in R's 'THANKS' file
>> {but that may not entice those who are already listed},
>> or even in the NEWS of the new relase
>> or on the "Hall of fame of R beta testers"
The latter sounds good to me, although I'm not sure how many of our
users are striving for fame ;).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Vaidotas Zemlys <[EMAIL PROTECTED]> writes: > Hi, > > On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > > > One further thought about this: > > > > On SUSE, > > > > rpm -qif /usr/share/mime/ > > > > points at > > > > http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo > > > > So I guess that the proper tree to bark at is the upstreams > > maintainers of > > > > http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz > > > > Instructions there say to submit new XML files to > > > > https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > > > It would likely be a good idea to send them first to R-devel for review. > > > > I already barked at upstream. The upstream barked back. The result is here: > > https://bugs.freedesktop.org/show_bug.cgi?id=1782 Aha... This is pretty weird, in light of the prescription on the website: << Shared MIME database package The core database and the update-mime-database program for extending it are available from the [WWW]software pages. If you have added types that should go in the common freedesktop.org base list of types, you should create an enhancement request on [WWW]the MIME bugtracker with your new XML file. >> If the procedure is different, perhaps we should ask them what it is? I don't think we have a real problem with maintaining a "freedesktop" subdir somewhere in the sources since it appears to cover quite a wide range of systems, but we don't seem to know what to do with it. The procedure appears to be different between Linuxen: On SUSE, I get viggo:~/>rpm -qf /usr/share/mime/text/x-texinfo.xml shared-mime-info-0.15.cvs20050321-3 whereas FC4 has [EMAIL PROTECTED] ~]$ rpm -qf /usr/share/mime/text/x-texinfo.xml file /usr/share/mime/text/x-texinfo.xml is not owned by any package (and likewise 60-odd other .xml files). So it seems that SUSE collects all this stuff in a single RPM and FC4 lets it be handled by the post-install mechanism (on each package or by "exploding" freedesktop.org.xml ??) > There you can find xml file for R scripts. I've made it from some > example. It is really only a proof of a concept. But it would not be > very difficult to produce xml files for mimetypes of all R related > files. We must only decide which R related files would benefit from > having mimetypes. > > My proposal is > 1. R source code, R scripts. Files with extensions .R, .r and others > (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc My inclination would be to stick with .R, possibly adding .r to guard against Windows case-folding issues, but .r used to be Ratfor files. .q/.s/.S are used by some people supporting both R and S-PLUS, but I don't think they care how such files are displayed by Nautilus and Konqueror... > 2. R documentation files. File extension .Rd. Mimetype text/x-Rd OK, modulo case-fold > 3. RData files. File extension .RData, files which at beginning have > RDX2. Mimetype application/x-RData. Why the RDX2 bit?? We do have .RDA from windows, too. > 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory OK. > 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype > text/x-Rtranscript .Rout, please. Also .Rout.save and .Rout.fail. (And it's not just ESS that creates them). Also 6. Rprofile files .Rprofile or Rprofile. > The relevant xml code could be pushed upstream to end up in > freedesktop.org.xml, or it could be distributed with R linux package, > and installed into relevant subdirectory of /usr/share/mime. With a > bit more work the result could be, that people using for example > Nautilus (graphical Gnome browser) could see R related files displayed > with R logo, and clicking them could result in various appropriate > actions. For example for .RData R process could be iinvoked and > relevant .RData file could be loaded. Some fun potential with gedit/Kate plugins too (ESS for the 21st century anyone?) > I could write and test the xml code. But first we have to agree on > which files benefit from having mimetypes and how the mimetypes should > be named. Feel free to suggest. -- 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] shared-mime-info (PR#8278)
Vaidotas Zemlys <[EMAIL PROTECTED]> writes: > Hi, > > On 04 Nov 2005 13:51:56 +0100, Peter Dalgaard <[EMAIL PROTECTED]> wrote: > > > One further thought about this: > > > > On SUSE, > > > > rpm -qif /usr/share/mime/ > > > > points at > > > > http://www.freedesktop.org/wiki/Software_2fshared_2dmime_2dinfo > > > > So I guess that the proper tree to bark at is the upstreams > > maintainers of > > > > http://freedesktop.org/~jrb/shared-mime-info-*.tar.gz > > > > Instructions there say to submit new XML files to > > > > https://bugs.freedesktop.org/buglist.cgi?product=shared-mime-info&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED > > > > It would likely be a good idea to send them first to R-devel for review. > > > > I already barked at upstream. The upstream barked back. The result is here: > > https://bugs.freedesktop.org/show_bug.cgi?id=1782 Aha... This is pretty weird, in light of the prescription on the website: << Shared MIME database package The core database and the update-mime-database program for extending it are available from the [WWW]software pages. If you have added types that should go in the common freedesktop.org base list of types, you should create an enhancement request on [WWW]the MIME bugtracker with your new XML file. >> If the procedure is different, perhaps we should ask them what it is? I don't think we have a real problem with maintaining a "freedesktop" subdir somewhere in the sources since it appears to cover quite a wide range of systems, but we don't seem to know what to do with it. The procedure appears to be different between Linuxen: On SUSE, I get viggo:~/>rpm -qf /usr/share/mime/text/x-texinfo.xml shared-mime-info-0.15.cvs20050321-3 whereas FC4 has [EMAIL PROTECTED] ~]$ rpm -qf /usr/share/mime/text/x-texinfo.xml file /usr/share/mime/text/x-texinfo.xml is not owned by any package (and likewise 60-odd other .xml files). So it seems that SUSE collects all this stuff in a single RPM and FC4 lets it be handled by the post-install mechanism (on each package or by "exploding" freedesktop.org.xml ??) > There you can find xml file for R scripts. I've made it from some > example. It is really only a proof of a concept. But it would not be > very difficult to produce xml files for mimetypes of all R related > files. We must only decide which R related files would benefit from > having mimetypes. > > My proposal is > 1. R source code, R scripts. Files with extensions .R, .r and others > (.q?, .s?, .S?). Mimetypes text/x-R, text/x-Rsrc My inclination would be to stick with .R, possibly adding .r to guard against Windows case-folding issues, but .r used to be Ratfor files. .q/.s/.S are used by some people supporting both R and S-PLUS, but I don't think they care how such files are displayed by Nautilus and Konqueror... > 2. R documentation files. File extension .Rd. Mimetype text/x-Rd OK, modulo case-fold > 3. RData files. File extension .RData, files which at beginning have > RDX2. Mimetype application/x-RData. Why the RDX2 bit?? We do have .RDA from windows, too. > 4. Rhistory files. File extension .Rhistory. Mimetype text/x-Rhistory OK. > 5. R transcript files from ESS/Emacs. File extension .Rt. Mimetype > text/x-Rtranscript .Rout, please. Also .Rout.save and .Rout.fail. (And it's not just ESS that creates them). Also 6. Rprofile files .Rprofile or Rprofile. > The relevant xml code could be pushed upstream to end up in > freedesktop.org.xml, or it could be distributed with R linux package, > and installed into relevant subdirectory of /usr/share/mime. With a > bit more work the result could be, that people using for example > Nautilus (graphical Gnome browser) could see R related files displayed > with R logo, and clicking them could result in various appropriate > actions. For example for .RData R process could be iinvoked and > relevant .RData file could be loaded. Some fun potential with gedit/Kate plugins too (ESS for the 21st century anyone?) > I could write and test the xml code. But first we have to agree on > which files benefit from having mimetypes and how the mimetypes should > be named. Feel free to suggest. -- 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
[Rd] dgamma error condition?
There's an apparent inconsistency between the behavior of d(pqr)gamma and other distribution functions for "bad" parameter values. Specifically, most distributions give NaN and a warning for bad parameters (e.g. probabilities <0 or >1). In contrast, d(pqr)gamma actually gives an error and stops when shape<0. I don't see why it has to be this way -- the internal C code is set up to detect shape<0 (or scale<0) and return NaN and a warning, and none of the other distribution functions in that bit of the code have similar behavior. It would seem more consistent (and would be more convenient for me -- the error-instead-of-warning is making me have to jump through additional hoops) if dgamma just returned NaN and a warning. Any thoughts? cheers Ben Bolker __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Changes to environments in R-devel
As a followup, these changes have some impacts on already installed packages, most likely including all those using lazy-loading or saved images. If you are building from a checked-out version of R you will need to trigger re-installation of the recommended packages. Unix users can do that by rm src/library/Recommended/*.ts make but Windows users will best do 'make distclean; make all recommended' as a clean is needed. One way to re-install all other packages is > have <- installed.packages(priority="NA")[,1] > install.packages(have) at least if you have them all in the main library tree or all in one additional tree. Doing it from within R ensures that the dependency order is maintained. If like me you have almost all CRAN packages installed that will take quite a while. Note that re-installing binary packages under Windows and MacOS X will not be effective until the repositories have been rebuilt. On Thu, 3 Nov 2005, Duncan Murdoch wrote: > I've just committed some changes to R-devel which affect environments. > Specifically: > > - using NULL as an environment is now deprecated: use baseenv() > instead. (baseenv() is already available in R 2.2.0, where it returns > NULL. For most purposes it retains the same meaning in R-devel.) If you > do use NULL, it will be converted to baseenv(), and a warning printed. > For example: > > > f <- function(x) 1 > > environment(f) <- NULL > Warning message: > use of NULL environment is deprecated > > environment(f) > > > There may be some places where I've missed putting the conversion in > place, and use of NULL will cause an error; please let me know if you > find any of those. The intention is that NULL will be usable with > warnings through to the end of the 2.3.x releases. > > - baseenv() is no longer its own parent. Its parent is an empty > environment, available as emptyenv(). > > - You can now create your own environment with emptyenv() as its > parent. Searches for variables in such an environment will not > automatically proceed to baseenv(), as searches do in current R releases. > > Duncan Murdoch > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- 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
[Rd] Classification Trees and basic Random Forest pkg using tree structures in C
Hello R-devel: I have written a package, called "woods", that does classification trees (R function CT), and currently, only the most basic functionality of Random Forest, e.g. bagged trees with choices about sample size, with/without replacement, size of (random) subset of covariates drawn when nodes are split. My reason for writing this is twofold. First, I wanted to base this development entirely in C (as others have done), but using data structures such as a node, pointer to node (for trees), and pointer to pointer of node (for forests) implemented in C. The algorithm which does bagging isn't any faster (its 30% slower) than one by Leo Breiman/Adele Cutler/Andy Liaw/ Matt Weiner. The CT function runs about equally as fast as Professor Brian Ripley's. The only interesting feature is that the tree structure has been implemented in C. Its a neater way to carry stuff around and I am guessing would make future implementation easier. Because of its inherent redundancy from the users standpoint, it isn't something to send to CRAN. However, I was wondering whether anyone is interested in a copy? Grant Izmirlian NCI __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] shared-mime-info (PR#8278)
Paul Roebuck <[EMAIL PROTECTED]> writes: > On Fri, 4 Nov 2005, Peter Dalgaard wrote: > > > Vaidotas Zemlys <[EMAIL PROTECTED]> writes: > > > > > [SNIP] > > > > > > > Also > > > > 6. Rprofile files .Rprofile or Rprofile. > > > > .Renviron? Yes, but you seem to have forgotten to keep r-devel in the circuit... -- 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
[Rd] R-2.2.0 Compile problem on Slackware 10.2
Hello, I am trying to compile R-2.2.0 on Slackware 10.2. I did ./configure --prefix=/usr --build=i486-slackware-linux. It went off without any problem and gave this configure status: R is now configured for i486-slackware-linux-gnu Source directory: . Installation directory:/usr C compiler:gcc -g -O2 C++ compiler: g++ -g -O2 Fortran compiler: g77 -g -O2 Interfaces supported: X11, tcltk External libraries:readline Additional capabilities: PNG, JPEG, iconv, MBCS, NLS Options enabled: R profiling Recommended packages: yes When I gave make command, I got the following error message: gcc -I. -DUSE_MMAP -I. -I../../../src/include -I../../../src/include -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c crc32.c -o crc32.o In file included from /usr/include/linux/errno.h:4, from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from zutil.h:38, from crc32.c:29: /usr/include/asm/errno.h:4:31: asm-generic/errno.h: No such file or directory make[4]: *** [crc32.o] Error 1 make[4]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' make[3]: *** [R] Error 2 make[3]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' make[2]: *** [R] Error 1 make[2]: Leaving directory `/home/anand/R-2.2.0/src/extra' make[1]: *** [R] Error 1 make[1]: Leaving directory `/home/anand/R-2.2.0/src' make: *** [R] Error 1 What should I do to correct this? Thanks for your help. Anand __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.2.0 Compile problem on Slackware 10.2
This an error in a standard system header file /usr/include/errno.h, not something we can help with. However, is --build=i486-slackware-linux actually correct? Our manuals do not suggest you specify --build, and if incorrect it might just explain this. On Fri, 4 Nov 2005, R S Ananda Murthy wrote: > Hello, > > I am trying to compile R-2.2.0 on Slackware 10.2. > > I did ./configure --prefix=/usr --build=i486-slackware-linux. It went > off without any problem and gave this configure status: > > R is now configured for i486-slackware-linux-gnu > > Source directory: . > Installation directory:/usr > > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: g77 -g -O2 > > Interfaces supported: X11, tcltk > External libraries:readline > Additional capabilities: PNG, JPEG, iconv, MBCS, NLS > Options enabled: R profiling > > Recommended packages: yes > > When I gave make command, I got the following error message: > > gcc -I. -DUSE_MMAP -I. -I../../../src/include -I../../../src/include > -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c crc32.c -o crc32.o > In file included from /usr/include/linux/errno.h:4, > from /usr/include/bits/errno.h:25, > from /usr/include/errno.h:36, > from zutil.h:38, > from crc32.c:29: > /usr/include/asm/errno.h:4:31: asm-generic/errno.h: No such file or > directory > make[4]: *** [crc32.o] Error 1 > make[4]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' > make[3]: *** [R] Error 2 > make[3]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' > make[2]: *** [R] Error 1 > make[2]: Leaving directory `/home/anand/R-2.2.0/src/extra' > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/home/anand/R-2.2.0/src' > make: *** [R] Error 1 > > What should I do to correct this? > > Thanks for your help. > > Anand > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > -- 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] Classification Trees and basic Random Forest pkg using tree structures in C
Izmirlian, Grant (NIH/NCI) wrote: > The only interesting feature is that the tree structure has been > implemented in C. Its a neater way to carry stuff around and I am > guessing would make future implementation easier. > > Because of its inherent redundancy from the users standpoint, it > isn't something to send to CRAN. However, I was wondering whether > anyone is interested in a copy? Hi, Hmm, why didn't you just post a URL? Incidentally I am actually very interested in seeing your code. I am working on a project where the data set is extremely large, but the permuntation of the states of the data is extremely small. Each piece of data consists of only 4 states, so stuffing it as an R object (which takes up 32-byte? on 32-bit machines) or even an char vector is quite wasteful; so I have written a "strange" data.frame where internally it uses only 2-bit for storage. (it is still work-in-process but I have got to the point of being able to get and set each 2-bit cell now). Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-2.2.0 Compile problem on Slackware 10.2
Your system is badly screwed up. On my Slackware 10.2, /usr/include/asm/errno.h is just a plain file and doesn't include anything else, unlike yours, which seems to look for "asm-generic/errno.h". The package you need to re-install is "kernel-headers-2.4.31-i386-1". It is part of the d series, on your slackware CD or wherever you got it installed from. On your box, the file is not missing but screwed up, so you should get somebody more experienced to take a look at your box and get it fixed before trying to uninstall/reinstall. Good luck. HTL P.S. for ix86, very old slackware [kernel 2.2 or before?] "asm/errno.h" is linked to "/usr/src/linux/include/asm-i386/errno.h" [because "/usr/include/asm" is linked to "/usr/src/linux/include/asm", which in turn is linked to "asm-i386" (I have an "asm-generic", which is just a link from asm-i386); for more modern boxes, "asm/errno.h" is just a plain file in a plain directory. R S Ananda Murthy wrote: > Hello, > > I am trying to compile R-2.2.0 on Slackware 10.2. > > I did ./configure --prefix=/usr --build=i486-slackware-linux. It went > off without any problem and gave this configure status: > > R is now configured for i486-slackware-linux-gnu > > Source directory: . > Installation directory:/usr > > C compiler:gcc -g -O2 > C++ compiler: g++ -g -O2 > Fortran compiler: g77 -g -O2 > > Interfaces supported: X11, tcltk > External libraries:readline > Additional capabilities: PNG, JPEG, iconv, MBCS, NLS > Options enabled: R profiling > > Recommended packages: yes > > When I gave make command, I got the following error message: > > gcc -I. -DUSE_MMAP -I. -I../../../src/include -I../../../src/include > -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c crc32.c -o crc32.o > In file included from /usr/include/linux/errno.h:4, > from /usr/include/bits/errno.h:25, > from /usr/include/errno.h:36, > from zutil.h:38, > from crc32.c:29: > /usr/include/asm/errno.h:4:31: asm-generic/errno.h: No such file or > directory > make[4]: *** [crc32.o] Error 1 > make[4]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' > make[3]: *** [R] Error 2 > make[3]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' > make[2]: *** [R] Error 1 > make[2]: Leaving directory `/home/anand/R-2.2.0/src/extra' > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/home/anand/R-2.2.0/src' > make: *** [R] Error 1 > > What should I do to correct this? > > Thanks for your help. > > Anand > > __ > 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] clarification of library/require semantics
Recently I have added a lib.loc argument to require, so that it is more consistent with library. However, there are some oddities that folks have pointed out, and we do not have a documented description of the semantics for what should happen when the lib.loc parameter is provided. Proposal: the most common use case seems to be one where any other dependencies, or calls to library/require should also see the library specified in the lib.loc parameter for the duration of the initial call to library. Hence, we should modify the library search path for the duration of the call (via .libPaths). The alternative, is to not do that. Which is what happens now. Both have costs, automatically setting the library search path, of course, means that users that do not want that behavior have to manually remove things from their library. But if almost no one does that, and most folks I have asked have said they want the lib.loc parameter to be used for other loading. Comments? Robert -- 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] Classification Trees and basic Random Forest pkg using tree structures in C
Hello Hin-Tak: Thanks for your interest. This is just a short not to tell you and others that the URL idea is a good one. This will take a few days at our organization. When its available I will post again to this thread. In the meantime, I will will send copies directly to those interested. So far, you and one other person. Regards, Grant __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Classification Trees and basic Random Forest pkg using t ree structures in C
> From: Hin-Tak Leung > > Izmirlian, Grant (NIH/NCI) wrote: > > > The only interesting feature is that the tree structure has been > > implemented in C. Its a neater way to carry stuff around and I am > > guessing would make future implementation easier. > > > > Because of its inherent redundancy from the users standpoint, it > > isn't something to send to CRAN. However, I was wondering whether > > anyone is interested in a copy? > > Hi, > > Hmm, why didn't you just post a URL? Isn't it a bit too much to assume that everyone has a personal web space somewhere? > Incidentally I am actually very > interested in seeing your code. I am working on a project where > the data set is extremely large, but the permuntation of the states of > the data is extremely small. Each piece of data consists of only 4 > states, so stuffing it as an R object (which takes up 32-byte? on > 32-bit machines) or even an char vector is quite wasteful; so I > have written a "strange" data.frame where internally it uses only > 2-bit for storage. (it is still work-in-process but I have got to > the point of being able to get and set each 2-bit cell now). For some of the data we encounter, all X variables are binary, so each data point can be encoded into a bitstring. There are algorithms that take advantage of that. The problem is interfacing such code with R. I know of no good solutions. As I told Grant, I thought about what he did, too, but the difficulty is how to pass such data structures to R. Actually, some time down the road I might try to use the dendrogram class that's in R, and manipulate them in C. Not sure about efficiency though. Andy > Hin-Tak Leung > > __ > 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] clarification of library/require semantics
On Fri, 4 Nov 2005, Robert Gentleman wrote: > Recently I have added a lib.loc argument to require, so that > it is more consistent with library. However, there are some oddities > that folks have pointed out, and we do not have a documented description > of the semantics for what should happen when the lib.loc parameter is > provided. > > Proposal: the most common use case seems to be one where any other > dependencies, or calls to library/require should also see the library > specified in the lib.loc parameter for the duration of the initial call > to library. Hence, we should modify the library search path for the > duration of the call (via .libPaths). > > The alternative, is to not do that. Which is what happens now. > > Both have costs, automatically setting the library search path, of > course, means that users that do not want that behavior have to manually > remove things from their library. But if almost no one does that, and > most folks I have asked have said they want the lib.loc parameter to be > used for other loading. > > Comments? There is a parallel set of issues with loadNamespace and the dependent namespaces it loads. I think I would want the same semantics (whatever they are) for loadNamespace and library. I set my standard libraries in R_LIBS, so when I use lib.loc it is for experimental things. So I would neither want the .libPaths changed nor be affected if they were. -- 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-2.2.0 Compile problem on Slackware 10.2
Dear HTL, Thanks for your help. I reinstalled kernel-headers-2.4.31 as mentioned by you. Now it compiled without any errors. Thanks again. Regards, Anand Hin-Tak Leung wrote: > Your system is badly screwed up. On my Slackware 10.2, > /usr/include/asm/errno.h is just a plain file and doesn't > include anything else, unlike yours, which seems to look > for "asm-generic/errno.h". > > The package you need to re-install is "kernel-headers-2.4.31-i386-1". > It is part of the d series, on your slackware CD or wherever you got > it installed from. On your box, the file is not missing but screwed > up, so you should get somebody more experienced to take a look at > your box and get it fixed before trying to uninstall/reinstall. > > Good luck. > HTL > > P.S. for ix86, very old slackware [kernel 2.2 or before?] "asm/errno.h" > is linked to "/usr/src/linux/include/asm-i386/errno.h" [because > "/usr/include/asm" is linked to "/usr/src/linux/include/asm", which > in turn is linked to "asm-i386" (I have an "asm-generic", which > is just a link from asm-i386); for more modern boxes, "asm/errno.h" > is just a plain file in a plain directory. > > R S Ananda Murthy wrote: > >> Hello, >> >> I am trying to compile R-2.2.0 on Slackware 10.2. >> >> I did ./configure --prefix=/usr --build=i486-slackware-linux. It went >> off without any problem and gave this configure status: >> >> R is now configured for i486-slackware-linux-gnu >> >> Source directory: . >> Installation directory:/usr >> >> C compiler:gcc -g -O2 >> C++ compiler: g++ -g -O2 >> Fortran compiler: g77 -g -O2 >> >> Interfaces supported: X11, tcltk >> External libraries:readline >> Additional capabilities: PNG, JPEG, iconv, MBCS, NLS >> Options enabled: R profiling >> >> Recommended packages: yes >> >> When I gave make command, I got the following error message: >> >> gcc -I. -DUSE_MMAP -I. -I../../../src/include -I../../../src/include >> -I/usr/local/include -DHAVE_CONFIG_H -g -O2 -c crc32.c -o crc32.o >> In file included from /usr/include/linux/errno.h:4, >> from /usr/include/bits/errno.h:25, >> from /usr/include/errno.h:36, >> from zutil.h:38, >> from crc32.c:29: >> /usr/include/asm/errno.h:4:31: asm-generic/errno.h: No such file or >> directory >> make[4]: *** [crc32.o] Error 1 >> make[4]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' >> make[3]: *** [R] Error 2 >> make[3]: Leaving directory `/home/anand/R-2.2.0/src/extra/zlib' >> make[2]: *** [R] Error 1 >> make[2]: Leaving directory `/home/anand/R-2.2.0/src/extra' >> make[1]: *** [R] Error 1 >> make[1]: Leaving directory `/home/anand/R-2.2.0/src' >> make: *** [R] Error 1 >> >> What should I do to correct this? >> >> Thanks for your help. >> >> Anand >> >> __ >> 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
