[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-infobug_status=NEWbug_status=ASSIGNEDbug_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-infobug_status=NEWbug_status=ASSIGNEDbug_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-infobug_status=NEWbug_status=ASSIGNEDbug_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-infobug_status=NEWbug_status=ASSIGNEDbug_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)
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: snipped 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
[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] 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
