From elff at sowi.uni-mannheim.de Sat Nov 1 12:09:07 2008 From: elff at sowi.uni-mannheim.de (Martin Elff) Date: Sat, 1 Nov 2008 12:09:07 +0100 Subject: [Rd] Small modification of zip.file.extract in utils? In-Reply-To: <490A062B.3010906@geo.uu.nl> References: <490A062B.3010906@geo.uu.nl> Message-ID: <200811011209.08173.elff@sowi.uni-mannheim.de> On Thursday 30 October 2008 (20:08:27), Jon Olav Skoien wrote: > Dear list, > > I needed to extract a zip-archive, and found zip.file.extract in utils. > My only problem was the use of tempdir(), since I wanted to permanently > extract the archive at a fixed location for later use. My own fix was > simple, adding an extra parameter zipdir (without default), and within > the function change > tmpd <- tempdir() > to > tmpd = ifelse(missing(zipdir),tempdir(),zipdir) > > This modification could maybe be useful also for other users, unless > there are some problems I am not aware of? I had similar problems with 'zip.file.extract' and implemented a function 'unzip' in my package 'memisc', which also works in a way that is probably more comprehensible for end-users like me: unzip package:memisc R Documentation Extract Files from Zip Files Description: 'unzip' extracts a file from a zip archive and puts them into a directory specified by the user or into the temporary directory of the current session. Usage: unzip(zipfile,item, dir=tempdir(),package=NULL) Arguments: zipfile: a character string, the path to the zip file. item: a character string, full path (from the root of the zip file) to the file to extract. dir: path to the directory were to place the extracted file. package: optional package name, if given, the path to the zipfile starts in the package's root directory. Examples: # Extract American National Election Study of 1948 # It is item "NES1948.POR" in zip file "anes/NES1948.ZIP" # where this path is relative to the packages' # root directory. nes1948.por <- unzip("anes/NES1948.ZIP","NES1948.POR", package="memisc") nes1948.por All the best, Martin From spencer.graves at pdf.com Sat Nov 1 16:40:33 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sat, 01 Nov 2008 08:40:33 -0700 Subject: [Rd] cat: ./R/Copy: No such file or directory Message-ID: <490C7871.6040008@pdf.com> Hello: What do you recommend I do to get past cryptic error messages from "R CMD check", complaining "No such file or directory"? The package is under SVN control, and I reverted to a version that passed "R CMD check", without eliminating the error. The "00install.out" file is short and bitter: cat: ./R/Copy: No such file or directory cat: of: No such file or directory cat: create.fourier.basis.R: No such file or directory make: *** [Rcode0] Error 1 ---------- Making package fda ------------ adding build stamp to DESCRIPTION installing NAMESPACE file and metadata make[2]: *** No rule to make target `R/Copy', needed by `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. Stop. make[1]: *** [all] Error 2 make: *** [pkg-fda] Error 2 *** Installation of fda failed *** Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' Thanks for any suggestions. I have a "*.tar.gz" file that I hope may not have this problem, but I'm not sure. Thanks, Spencer From Ted.Harding at manchester.ac.uk Sat Nov 1 17:19:59 2008 From: Ted.Harding at manchester.ac.uk ( (Ted Harding)) Date: Sat, 01 Nov 2008 16:19:59 -0000 (GMT) Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: <490C7871.6040008@pdf.com> Message-ID: Just guessing here, but it looks as though an attempt has been made to execute the following command: cat ./R/Copy of create.fourier.basis.R This may have arisen because there is indeed a file named "Copy of create.fourier.basis.R" but the command was issued to the OS without quotes; or (perhaps less likely, because of the presence of the "./R/") the line "Copy of create.fourier.basis.R" was intended as a comment in the file, but somehow got read as a substantive part of the code. Good luck! Ted. On 01-Nov-08 15:40:33, Spencer Graves wrote: > Hello: > > What do you recommend I do to get past cryptic error messages > from > "R CMD check", complaining "No such file or directory"? The package is > under SVN control, and I reverted to a version that passed "R CMD > check", without eliminating the error. The "00install.out" file is > short and bitter: > > > cat: ./R/Copy: No such file or directory > cat: of: No such file or directory > cat: create.fourier.basis.R: No such file or directory > make: *** [Rcode0] Error 1 > > ---------- Making package fda ------------ > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > make[2]: *** No rule to make target `R/Copy', needed by > `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. > Stop. > make[1]: *** [all] Error 2 > make: *** [pkg-fda] Error 2 > *** Installation of fda failed *** > > Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' > > > Thanks for any suggestions. I have a "*.tar.gz" file that I hope > may not have this problem, but I'm not sure. > > Thanks, > Spencer > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -------------------------------------------------------------------- E-Mail: (Ted Harding) Fax-to-email: +44 (0)870 094 0861 Date: 01-Nov-08 Time: 16:19:56 ------------------------------ XFMail ------------------------------ From spencer.graves at pdf.com Sun Nov 2 01:53:43 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sat, 01 Nov 2008 17:53:43 -0700 Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: References: Message-ID: <490CFA17.8000605@pdf.com> Dear Ted: Thanks very much. In fact, I did have a file named "Copy of create.fourier.basis.R". I deleted it and got an even more cryptic version of the same error message. I ultimately traced this to lines like "<<<<<<< .working" inserted by subversion into a *.R or *.Rd file I was using. I found this by finding a previous "*.tar.gz" file that passed "R CMD check", studying the subversion log of 7 different changes made by 3 people since that one that worked, and reviewing changes made to at least 13 different files in that period until I found the problem. Best Wishes, Spencer (Ted Harding) wrote: > Just guessing here, but it looks as though an attempt has been made > to execute the following command: > > cat ./R/Copy of create.fourier.basis.R > > This may have arisen because there is indeed a file named > > "Copy of create.fourier.basis.R" > > but the command was issued to the OS without quotes; or (perhaps > less likely, because of the presence of the "./R/") the line > > "Copy of create.fourier.basis.R" > > was intended as a comment in the file, but somehow got read as > a substantive part of the code. > > Good luck! > Ted. > > On 01-Nov-08 15:40:33, Spencer Graves wrote: > >> Hello: >> >> What do you recommend I do to get past cryptic error messages >> from >> "R CMD check", complaining "No such file or directory"? The package is >> under SVN control, and I reverted to a version that passed "R CMD >> check", without eliminating the error. The "00install.out" file is >> short and bitter: >> >> >> cat: ./R/Copy: No such file or directory >> cat: of: No such file or directory >> cat: create.fourier.basis.R: No such file or directory >> make: *** [Rcode0] Error 1 >> >> ---------- Making package fda ------------ >> adding build stamp to DESCRIPTION >> installing NAMESPACE file and metadata >> make[2]: *** No rule to make target `R/Copy', needed by >> `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. >> Stop. >> make[1]: *** [all] Error 2 >> make: *** [pkg-fda] Error 2 >> *** Installation of fda failed *** >> >> Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' >> >> >> Thanks for any suggestions. I have a "*.tar.gz" file that I hope >> may not have this problem, but I'm not sure. >> >> Thanks, >> Spencer >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -------------------------------------------------------------------- > E-Mail: (Ted Harding) > Fax-to-email: +44 (0)870 094 0861 > Date: 01-Nov-08 Time: 16:19:56 > ------------------------------ XFMail ------------------------------ > From murdoch at stats.uwo.ca Sun Nov 2 02:35:43 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Sat, 01 Nov 2008 21:35:43 -0400 Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: <490CFA17.8000605@pdf.com> References: <490CFA17.8000605@pdf.com> Message-ID: <490D03EF.6090805@stats.uwo.ca> On 01/11/2008 8:53 PM, Spencer Graves wrote: > Dear Ted: > > Thanks very much. In fact, I did have a file named "Copy of > create.fourier.basis.R". I deleted it and got an even more cryptic > version of the same error message. I ultimately traced this to lines > like "<<<<<<< .working" inserted by subversion into a *.R or *.Rd file I > was using. I found this by finding a previous "*.tar.gz" file that > passed "R CMD check", studying the subversion log of 7 different changes > made by 3 people since that one that worked, and reviewing changes made > to at least 13 different files in that period until I found the problem. Hi Spencer. If you're using Windows, I really recommend using TortoiseSVN. It'll make it very easy to see conflict markers like the one that caused your trouble. (I don't like their compare utility, but it's easy to plug in a different one. I use Beyond Compare.) If you're not on Windows, there are probably similar things available, but I don't know what they are. Duncan Murdoch > > Best Wishes, > Spencer > > (Ted Harding) wrote: >> Just guessing here, but it looks as though an attempt has been made >> to execute the following command: >> >> cat ./R/Copy of create.fourier.basis.R >> >> This may have arisen because there is indeed a file named >> >> "Copy of create.fourier.basis.R" >> >> but the command was issued to the OS without quotes; or (perhaps >> less likely, because of the presence of the "./R/") the line >> >> "Copy of create.fourier.basis.R" >> >> was intended as a comment in the file, but somehow got read as >> a substantive part of the code. >> >> Good luck! >> Ted. >> >> On 01-Nov-08 15:40:33, Spencer Graves wrote: >> >>> Hello: >>> >>> What do you recommend I do to get past cryptic error messages >>> from >>> "R CMD check", complaining "No such file or directory"? The package is >>> under SVN control, and I reverted to a version that passed "R CMD >>> check", without eliminating the error. The "00install.out" file is >>> short and bitter: >>> >>> >>> cat: ./R/Copy: No such file or directory >>> cat: of: No such file or directory >>> cat: create.fourier.basis.R: No such file or directory >>> make: *** [Rcode0] Error 1 >>> >>> ---------- Making package fda ------------ >>> adding build stamp to DESCRIPTION >>> installing NAMESPACE file and metadata >>> make[2]: *** No rule to make target `R/Copy', needed by >>> `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. >>> Stop. >>> make[1]: *** [all] Error 2 >>> make: *** [pkg-fda] Error 2 >>> *** Installation of fda failed *** >>> >>> Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' >>> >>> >>> Thanks for any suggestions. I have a "*.tar.gz" file that I hope >>> may not have this problem, but I'm not sure. >>> >>> Thanks, >>> Spencer >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> -------------------------------------------------------------------- >> E-Mail: (Ted Harding) >> Fax-to-email: +44 (0)870 094 0861 >> Date: 01-Nov-08 Time: 16:19:56 >> ------------------------------ XFMail ------------------------------ >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From spencer.graves at pdf.com Sun Nov 2 03:19:30 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sat, 01 Nov 2008 19:19:30 -0700 Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: <490D03EF.6090805@stats.uwo.ca> References: <490CFA17.8000605@pdf.com> <490D03EF.6090805@stats.uwo.ca> Message-ID: <490D0E32.5010703@pdf.com> Dear Duncan: Duncan Murdoch wrote: > On 01/11/2008 8:53 PM, Spencer Graves wrote: >> Dear Ted: >> Thanks very much. In fact, I did have a file named "Copy of >> create.fourier.basis.R". I deleted it and got an even more cryptic >> version of the same error message. I ultimately traced this to lines >> like "<<<<<<< .working" inserted by subversion into a *.R or *.Rd >> file I was using. I found this by finding a previous "*.tar.gz" file >> that passed "R CMD check", studying the subversion log of 7 different >> changes made by 3 people since that one that worked, and reviewing >> changes made to at least 13 different files in that period until I >> found the problem. > > Hi Spencer. > > If you're using Windows, I really recommend using TortoiseSVN. It'll > make it very easy to see conflict markers like the one that caused > your trouble. (I don't like their compare utility, but it's easy to > plug in a different one. I use Beyond Compare.) I've been using TortoiseSVN for roughly 18 months now, but I had previously not used much of its capabilities. The log and diff files helped narrow the problem from someplace in 400 files to someplace in 13. It would be nice if the "R CMD check" diagnostics were more clear about things like this. However, even with these problems, it is vastly superior to the anarchy that organizes the software development efforts of many people I know. I have friends and colleagues developing software in other languages with NOTHING like this, asking me to check their work. I'm refining lectures on the virtues of "R CMD check" and pushing others adopt something similar for perl scripts, Matlab code, etc. I'm eager to help develop such systems, and I resist efforts to have me repeat tests I developed months ago and should be automated. Thanks for your reply -- and for your very valuable work in helping to develop the current "R CMD check" system. Best Wishes, Spencer > > If you're not on Windows, there are probably similar things available, > but I don't know what they are. > > Duncan Murdoch > >> >> Best Wishes, >> Spencer >> >> (Ted Harding) wrote: >>> Just guessing here, but it looks as though an attempt has been made >>> to execute the following command: >>> >>> cat ./R/Copy of create.fourier.basis.R >>> >>> This may have arisen because there is indeed a file named >>> >>> "Copy of create.fourier.basis.R" >>> >>> but the command was issued to the OS without quotes; or (perhaps >>> less likely, because of the presence of the "./R/") the line >>> >>> "Copy of create.fourier.basis.R" >>> >>> was intended as a comment in the file, but somehow got read as >>> a substantive part of the code. >>> >>> Good luck! >>> Ted. >>> >>> On 01-Nov-08 15:40:33, Spencer Graves wrote: >>> >>>> Hello: >>>> What do you recommend I do to get past cryptic error messages >>>> from "R CMD check", complaining "No such file or directory"? The >>>> package is >>>> under SVN control, and I reverted to a version that passed "R CMD >>>> check", without eliminating the error. The "00install.out" file is >>>> short and bitter: >>>> >>>> cat: ./R/Copy: No such file or directory >>>> cat: of: No such file or directory >>>> cat: create.fourier.basis.R: No such file or directory >>>> make: *** [Rcode0] Error 1 >>>> >>>> ---------- Making package fda ------------ >>>> adding build stamp to DESCRIPTION >>>> installing NAMESPACE file and metadata >>>> make[2]: *** No rule to make target `R/Copy', needed by >>>> `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. >>>> Stop. >>>> make[1]: *** [all] Error 2 >>>> make: *** [pkg-fda] Error 2 >>>> *** Installation of fda failed *** >>>> >>>> Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' >>>> >>>> Thanks for any suggestions. I have a "*.tar.gz" file >>>> that I hope >>>> may not have this problem, but I'm not sure. >>>> Thanks, >>>> Spencer >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> -------------------------------------------------------------------- >>> E-Mail: (Ted Harding) >>> Fax-to-email: +44 (0)870 094 0861 >>> Date: 01-Nov-08 Time: 16:19:56 >>> ------------------------------ XFMail ------------------------------ >>> >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > From ripley at stats.ox.ac.uk Sun Nov 2 08:08:28 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Sun, 2 Nov 2008 07:08:28 +0000 (GMT) Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: <490D0E32.5010703@pdf.com> References: <490CFA17.8000605@pdf.com> <490D03EF.6090805@stats.uwo.ca> <490D0E32.5010703@pdf.com> Message-ID: Please note that the assmuption is that you can install a pacakge before you check it. R CMD INSTALL often gives fuller diagnostics: I am not sure these would have helped you here, but I would have expected you to have got a 'syntax error' message (which is not 'cryptic': you did have syntax errors in your files). On Sat, 1 Nov 2008, Spencer Graves wrote: > Dear Duncan: > > > Duncan Murdoch wrote: >> On 01/11/2008 8:53 PM, Spencer Graves wrote: >>> Dear Ted: >>> Thanks very much. In fact, I did have a file named "Copy of >>> create.fourier.basis.R". I deleted it and got an even more cryptic >>> version of the same error message. I ultimately traced this to lines like >>> "<<<<<<< .working" inserted by subversion into a *.R or *.Rd file I was >>> using. I found this by finding a previous "*.tar.gz" file that passed "R >>> CMD check", studying the subversion log of 7 different changes made by 3 >>> people since that one that worked, and reviewing changes made to at least >>> 13 different files in that period until I found the problem. >> >> Hi Spencer. >> >> If you're using Windows, I really recommend using TortoiseSVN. It'll make >> it very easy to see conflict markers like the one that caused your trouble. >> (I don't like their compare utility, but it's easy to plug in a different >> one. I use Beyond Compare.) > I've been using TortoiseSVN for roughly 18 months now, but I had > previously not used much of its capabilities. The log and diff files helped > narrow the problem from someplace in 400 files to someplace in 13. > It would be nice if the "R CMD check" diagnostics were more clear about > things like this. However, even with these problems, it is vastly superior > to the anarchy that organizes the software development efforts of many people > I know. I have friends and colleagues developing software in other languages > with NOTHING like this, asking me to check their work. I'm refining lectures > on the virtues of "R CMD check" and pushing others adopt something similar > for perl scripts, Matlab code, etc. I'm eager to help develop such systems, > and I resist efforts to have me repeat tests I developed months ago and > should be automated. > Thanks for your reply -- and for your very valuable work in helping to > develop the current "R CMD check" system. > Best Wishes, > Spencer >> >> If you're not on Windows, there are probably similar things available, but >> I don't know what they are. >> >> Duncan Murdoch >> >>> >>> Best Wishes, >>> Spencer >>> >>> (Ted Harding) wrote: >>>> Just guessing here, but it looks as though an attempt has been made >>>> to execute the following command: >>>> >>>> cat ./R/Copy of create.fourier.basis.R >>>> >>>> This may have arisen because there is indeed a file named >>>> >>>> "Copy of create.fourier.basis.R" >>>> >>>> but the command was issued to the OS without quotes; or (perhaps >>>> less likely, because of the presence of the "./R/") the line >>>> >>>> "Copy of create.fourier.basis.R" >>>> >>>> was intended as a comment in the file, but somehow got read as >>>> a substantive part of the code. >>>> >>>> Good luck! >>>> Ted. >>>> >>>> On 01-Nov-08 15:40:33, Spencer Graves wrote: >>>> >>>>> Hello: >>>>> What do you recommend I do to get past cryptic error messages >>>>> from "R CMD check", complaining "No such file or directory"? The >>>>> package is >>>>> under SVN control, and I reverted to a version that passed "R CMD >>>>> check", without eliminating the error. The "00install.out" file is >>>>> short and bitter: >>>>> >>>>> cat: ./R/Copy: No such file or directory >>>>> cat: of: No such file or directory >>>>> cat: create.fourier.basis.R: No such file or directory >>>>> make: *** [Rcode0] Error 1 >>>>> >>>>> ---------- Making package fda ------------ >>>>> adding build stamp to DESCRIPTION >>>>> installing NAMESPACE file and metadata >>>>> make[2]: *** No rule to make target `R/Copy', needed by >>>>> `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. >>>>> Stop. >>>>> make[1]: *** [all] Error 2 >>>>> make: *** [pkg-fda] Error 2 >>>>> *** Installation of fda failed *** >>>>> >>>>> Removing 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' >>>>> >>>>> Thanks for any suggestions. I have a "*.tar.gz" file that I >>>>> hope >>>>> may not have this problem, but I'm not sure. >>>>> Thanks, >>>>> Spencer >>>>> >>>>> ______________________________________________ >>>>> R-devel at r-project.org mailing list >>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>> >>>> -------------------------------------------------------------------- >>>> E-Mail: (Ted Harding) >>>> Fax-to-email: +44 (0)870 094 0861 >>>> Date: 01-Nov-08 Time: 16:19:56 >>>> ------------------------------ XFMail ------------------------------ >>>> >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From deepayan.sarkar at gmail.com Sun Nov 2 09:04:01 2008 From: deepayan.sarkar at gmail.com (Deepayan Sarkar) Date: Sun, 2 Nov 2008 01:04:01 -0700 Subject: [Rd] Emacs tags for R code Message-ID: Hi, I have put up details of a new tool for tagging R code at http://dsarkar.fhcrc.org/rtags/rtags.html that Emacs/ESS users may be interested in. It should be possible to extend this for other editors as well. Comments and feedback welcome. -Deepayan From ggrothendieck at gmail.com Sun Nov 2 15:33:51 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sun, 2 Nov 2008 09:33:51 -0500 Subject: [Rd] Wishlist: pass args from demo() to source() Message-ID: <971536df0811020633u13116fc0x50550cda3c1285b6@mail.gmail.com> Currently demo calls source with a hard coded max.deparse.length = 250 so you can't really see the demo properly in some cases. Note the [TRUNCATED] below. (1) It would be nice if demo passed max.deparse.length (and other args to source). (2) Also a larger max.deparse.length default would be nice to make it less likely one would have to set it in the first place. > R.version.string # Vista [1] "R version 2.8.0 Patched (2008-10-21 r46766)" > demo("gsubfn-si") demo(gsubfn-si) ---- ~~~~~~~~~ Type to start : > # given number possibly followed by SI letter (e.g. 32.5k where k means 1000) > # replace letter with e followed by appropriate digits. > # (see formatEng2R by Hans-Joerg Bibiko in the R Wiki) > > conv <- list(y = "e-24", z = "e-21", a = "e-18", f .... [TRUNCATED] > gsubfn(".$", conv, c("19", "32.5M")) [1] "19" "32.5e6" From murdoch at stats.uwo.ca Sun Nov 2 16:19:29 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Sun, 02 Nov 2008 10:19:29 -0500 Subject: [Rd] Wishlist: pass args from demo() to source() In-Reply-To: <971536df0811020633u13116fc0x50550cda3c1285b6@mail.gmail.com> References: <971536df0811020633u13116fc0x50550cda3c1285b6@mail.gmail.com> Message-ID: <490DC501.1070404@stats.uwo.ca> On 02/11/2008 9:33 AM, Gabor Grothendieck wrote: > Currently demo calls source with a hard coded max.deparse.length = 250 > so you can't really see the demo properly in some cases. Note the > [TRUNCATED] below. (1) It would be nice if demo passed max.deparse.length > (and other args to source). (2) Also a larger max.deparse.length default would > be nice to make it less likely one would have to set it in the first place. I can see increasing the default, but it doesn't really seem like a good design to give extra args to demo(). Would users ever know about them? So to me the choice would be to set a large max.deparse.length in the call to source() from demo(). Just for fun, I tracked down the revision where the 250 value was introduced: it was in r3045 in December 1998 on https://svn.r-project.org/R/branches/R-0-63-patches/src/library/base/R/source.R, where the max was decreased from 10000 to 250. (The demo() function was in source.R in those days.) And the 10000 was added in r354 in December 1997 to https://svn.r-project.org/R/trunk/src/library/base/R/source, to remove the TRUNCATED message. Martin, is there any chance you remember what problem the 10000 caused? If those problems still exist, I'd add an arg to demo with 250 as the default, but if not, I'd say putting it back as 10000 would be reasonable. Duncan Murdoch > >> R.version.string # Vista > [1] "R version 2.8.0 Patched (2008-10-21 r46766)" >> demo("gsubfn-si") > > > demo(gsubfn-si) > ---- ~~~~~~~~~ > > Type to start : > >> # given number possibly followed by SI letter (e.g. 32.5k where k means 1000) >> # replace letter with e followed by appropriate digits. >> # (see formatEng2R by Hans-Joerg Bibiko in the R Wiki) >> >> conv <- list(y = "e-24", z = "e-21", a = "e-18", f .... [TRUNCATED] > >> gsubfn(".$", conv, c("19", "32.5M")) > [1] "19" "32.5e6" > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From spencer.graves at pdf.com Sun Nov 2 16:29:50 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sun, 02 Nov 2008 07:29:50 -0800 Subject: [Rd] cat: ./R/Copy: No such file or directory In-Reply-To: References: <490CFA17.8000605@pdf.com> <490D03EF.6090805@stats.uwo.ca> <490D0E32.5010703@pdf.com> Message-ID: <490DC76E.6010300@pdf.com> Dear Prof. Ripley: Thanks for the suggestion. I've used some of those diagnostics, and I think I knew that I could run "R CMD install --build" without having passed "R CMD check", but I hadn't done it before and didn't think of it. I will remember it for the future. Best Wishes, Spencer Prof Brian Ripley wrote: > Please note that the assmuption is that you can install a pacakge > before you check it. > > R CMD INSTALL often gives fuller diagnostics: I am not sure these > would have helped you here, but I would have expected you to have got > a 'syntax error' message (which is not 'cryptic': you did have syntax > errors in your files). > > On Sat, 1 Nov 2008, Spencer Graves wrote: > >> Dear Duncan: >> >> Duncan Murdoch wrote: >>> On 01/11/2008 8:53 PM, Spencer Graves wrote: >>>> Dear Ted: >>>> Thanks very much. In fact, I did have a file named "Copy of >>>> create.fourier.basis.R". I deleted it and got an even more cryptic >>>> version of the same error message. I ultimately traced this to >>>> lines like "<<<<<<< .working" inserted by subversion into a *.R or >>>> *.Rd file I was using. I found this by finding a previous >>>> "*.tar.gz" file that passed "R CMD check", studying the subversion >>>> log of 7 different changes made by 3 people since that one that >>>> worked, and reviewing changes made to at least 13 different files >>>> in that period until I found the problem. >>> >>> Hi Spencer. >>> >>> If you're using Windows, I really recommend using TortoiseSVN. >>> It'll make it very easy to see conflict markers like the one that >>> caused your trouble. (I don't like their compare utility, but it's >>> easy to plug in a different one. I use Beyond Compare.) >> I've been using TortoiseSVN for roughly 18 months now, but I had >> previously not used much of its capabilities. The log and diff files >> helped narrow the problem from someplace in 400 files to someplace in >> 13. >> It would be nice if the "R CMD check" diagnostics were more clear >> about things like this. However, even with these problems, it is >> vastly superior to the anarchy that organizes the software >> development efforts of many people I know. I have friends and >> colleagues developing software in other languages with NOTHING like >> this, asking me to check their work. I'm refining lectures on the >> virtues of "R CMD check" and pushing others adopt something similar >> for perl scripts, Matlab code, etc. I'm eager to help develop such >> systems, and I resist efforts to have me repeat tests I developed >> months ago and should be automated. >> Thanks for your reply -- and for your very valuable work in >> helping to develop the current "R CMD check" system. >> Best Wishes, >> Spencer >>> >>> If you're not on Windows, there are probably similar things >>> available, but I don't know what they are. >>> >>> Duncan Murdoch >>> >>>> >>>> Best Wishes, >>>> Spencer >>>> >>>> (Ted Harding) wrote: >>>>> Just guessing here, but it looks as though an attempt has been made >>>>> to execute the following command: >>>>> >>>>> cat ./R/Copy of create.fourier.basis.R >>>>> >>>>> This may have arisen because there is indeed a file named >>>>> >>>>> "Copy of create.fourier.basis.R" >>>>> >>>>> but the command was issued to the OS without quotes; or (perhaps >>>>> less likely, because of the presence of the "./R/") the line >>>>> >>>>> "Copy of create.fourier.basis.R" >>>>> >>>>> was intended as a comment in the file, but somehow got read as >>>>> a substantive part of the code. >>>>> >>>>> Good luck! >>>>> Ted. >>>>> >>>>> On 01-Nov-08 15:40:33, Spencer Graves wrote: >>>>> >>>>>> Hello: >>>>>> What do you recommend I do to get past cryptic error messages >>>>>> from "R CMD check", complaining "No such file or directory"? The >>>>>> package is >>>>>> under SVN control, and I reverted to a version that passed "R CMD >>>>>> check", without eliminating the error. The "00install.out" file >>>>>> is short and bitter: >>>>>> >>>>>> cat: ./R/Copy: No such file or directory >>>>>> cat: of: No such file or directory >>>>>> cat: create.fourier.basis.R: No such file or directory >>>>>> make: *** [Rcode0] Error 1 >>>>>> >>>>>> ---------- Making package fda ------------ >>>>>> adding build stamp to DESCRIPTION >>>>>> installing NAMESPACE file and metadata >>>>>> make[2]: *** No rule to make target `R/Copy', needed by >>>>>> `D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda/R/fda'. >>>>>> Stop. >>>>>> make[1]: *** [all] Error 2 >>>>>> make: *** [pkg-fda] Error 2 >>>>>> *** Installation of fda failed *** >>>>>> >>>>>> Removing >>>>>> 'D:/spencerg/statmtds/splines/fda/RForge/fda/fda.Rcheck/fda' >>>>>> >>>>>> Thanks for any suggestions. I have a "*.tar.gz" file >>>>>> that I hope >>>>>> may not have this problem, but I'm not sure. >>>>>> Thanks, >>>>>> Spencer >>>>>> >>>>>> ______________________________________________ >>>>>> R-devel at r-project.org mailing list >>>>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>>>> >>>>> -------------------------------------------------------------------- >>>>> E-Mail: (Ted Harding) >>>>> Fax-to-email: +44 (0)870 094 0861 >>>>> Date: 01-Nov-08 Time: 16:19:56 >>>>> ------------------------------ XFMail ------------------------------ >>>>> >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From spencer.graves at pdf.com Sun Nov 2 18:40:39 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sun, 02 Nov 2008 09:40:39 -0800 Subject: [Rd] R CMD check with Matlab and perl? Message-ID: <490DE617.40104@pdf.com> Hi, All: How might one test Matlab and perl code during "R CMD check"? I ask for two reasons: First, the "fda" package exists in both R and Matlab, and it would help if we could run test examples in Matlab as part of "R CMD check". I tried "R.matlab", but could not get it to work in that context. Second, I have professional colleagues who write code in Matlab and perl, but have no unit or regression testing. If I could test Matlab and perl from within "R CMD check" examples, I think I could get them to use it, because it would produce more "trustworthy software" [the "Prime Directive" of Chambers (2008) Software for Data Analysis (Springer)] AND give them documentation at the same time -- while simultaneously reducing the cost of producing and maintaining code to given specifications. Thanks, Spencer From mel at altk.com Sun Nov 2 18:40:19 2008 From: mel at altk.com (mel) Date: Sun, 02 Nov 2008 18:40:19 +0100 Subject: [Rd] Thanks for R-2.8.0 still on W2000 Message-ID: <490DE603.5060402@altk.com> Hello, This little post is just to thank Prof. Ripley and the R team for still maintaining R runable on Windows 2000. I installed R-2.8.0 on Windows 2000 and used it for several computation hours and everything seems to work fine. Many thanks Vincent From murdoch at stats.uwo.ca Sun Nov 2 18:46:47 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Sun, 02 Nov 2008 12:46:47 -0500 Subject: [Rd] R CMD check with Matlab and perl? In-Reply-To: <490DE617.40104@pdf.com> References: <490DE617.40104@pdf.com> Message-ID: <490DE787.7040209@stats.uwo.ca> Spencer Graves wrote: > Hi, All: > > How might one test Matlab and perl code during "R CMD check"? > > I ask for two reasons: First, the "fda" package exists in both R > and Matlab, and it would help if we could run test examples in Matlab as > part of "R CMD check". I tried "R.matlab", but could not get it to work > in that context. > Can you run the tests from the command line? If so, you should be able to call them from system() in a script in the tests directory, or in an example section of an Rd file. Duncan Murdoch > Second, I have professional colleagues who write code in Matlab > and perl, but have no unit or regression testing. If I could test > Matlab and perl from within "R CMD check" examples, I think I could get > them to use it, because it would produce more "trustworthy software" > [the "Prime Directive" of Chambers (2008) Software for Data Analysis > (Springer)] AND give them documentation at the same time -- while > simultaneously reducing the cost of producing and maintaining code to > given specifications. > > > Thanks, > Spencer > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From maechler at stat.math.ethz.ch Mon Nov 3 09:19:31 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Mon, 3 Nov 2008 09:19:31 +0100 Subject: [Rd] Wishlist: pass args from demo() to source() In-Reply-To: <490DC501.1070404@stats.uwo.ca> References: <971536df0811020633u13116fc0x50550cda3c1285b6@mail.gmail.com> <490DC501.1070404@stats.uwo.ca> Message-ID: <18702.46099.86890.140314@stat.math.ethz.ch> >>>>> "DM" == Duncan Murdoch >>>>> on Sun, 02 Nov 2008 10:19:29 -0500 writes: DM> On 02/11/2008 9:33 AM, Gabor Grothendieck wrote: >> Currently demo calls source with a hard coded >> max.deparse.length = 250 so you can't really see the demo >> properly in some cases. Note the [TRUNCATED] below. (1) >> It would be nice if demo passed max.deparse.length (and >> other args to source). (2) Also a larger >> max.deparse.length default would be nice to make it less >> likely one would have to set it in the first place. DM> I can see increasing the default, but it doesn't really DM> seem like a good design to give extra args to demo(). DM> Would users ever know about them? DM> So to me the choice would be to set a large DM> max.deparse.length in the call to source() from demo(). DM> Just for fun, I tracked down the revision where the 250 DM> value was introduced: it was in r3045 in December 1998 DM> on DM> https://svn.r-project.org/R/branches/R-0-63-patches/src/library/base/R/source.R, DM> where the max was decreased from 10000 to 250. (The DM> demo() function was in source.R in those days.) And the DM> 10000 was added in r354 in December 1997 to DM> https://svn.r-project.org/R/trunk/src/library/base/R/source, DM> to remove the TRUNCATED message. DM> Martin, is there any chance you remember what problem DM> the 10000 caused? If those problems still exist, I'd DM> add an arg to demo with 250 as the default, but if not, DM> I'd say putting it back as 10000 would be reasonable. No, I don't remember. The change in December 1998 you mention contained more important things than s/10000/250/. In the mean time, we have example() calling source(..., max.deparse.length = Inf, ....) and I think we should do the same for demo(). "Arbitrary limits" is against the GNU coding standards. Martin DM> Duncan Murdoch >> >>> R.version.string # Vista >> [1] "R version 2.8.0 Patched (2008-10-21 r46766)" >>> demo("gsubfn-si") >> >> >> demo(gsubfn-si) ---- ~~~~~~~~~ >> >> Type to start : >> >>> # given number possibly followed by SI letter >>> (e.g. 32.5k where k means 1000) # replace letter with e >>> followed by appropriate digits. # (see formatEng2R by >>> Hans-Joerg Bibiko in the R Wiki) >>> >>> conv <- list(y = "e-24", z = "e-21", a = "e-18", f >>> .... [TRUNCATED] >> >>> gsubfn(".$", conv, c("19", "32.5M")) >> [1] "19" "32.5e6" >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel DM> ______________________________________________ DM> R-devel at r-project.org mailing list DM> https://stat.ethz.ch/mailman/listinfo/r-devel From jbonsdorff at gmail.com Sun Nov 2 17:10:04 2008 From: jbonsdorff at gmail.com (jbonsdorff at gmail.com) Date: Sun, 2 Nov 2008 17:10:04 +0100 (CET) Subject: [Rd] R.app data editor crashes with empty data frame (PR#13239) Message-ID: <20081102161004.175C6282EF48@mail.pubhealth.ku.dk> Full_Name: Juhani Bonsdorff Version: 2.8.0 OS: OS X Leopard 10.5.5 Submission from: (NULL) (91.153.255.102) Installed the latest R.app (v1.26, R version 2.8.0) binary package from CRAN. The GUI data editor crashes when applied to an empty data frame: entering df <- edit(data.frame()) the editor opens with completely empty screen, i.e., without any column names. Now trying to add column or row hangs the application. Sometimes the following is written in the R Console just before the GUI hangs: SET_VECTOR_ELT can only be applied to a 'list', not a 'NULL'. On other occasions R hangs without any messages. In all cases force quit is the only option to exit R. The behaviour is not present with empty matrices: there the first default column is visible and editor allows the addition of new rows as well as columns. From bert.tijhuis at wavin.com Mon Nov 3 08:15:07 2008 From: bert.tijhuis at wavin.com (bert.tijhuis at wavin.com) Date: Mon, 3 Nov 2008 08:15:07 +0100 (CET) Subject: [Rd] sort returns a wrong index (PR#13242) Message-ID: <20081103071507.5E6BF282EF48@mail.pubhealth.ku.dk> Full_Name: Bert Tijhuis Version: 2.8.0 OS: MS-Windows Submission from: (NULL) (217.140.7.52) > xd [1] 0.5 -1.0 0.2 NA -3.0 1.0 2.0 NA 2.0 > sort(xd, index=T)$ix [1] 4 2 3 1 5 6 7 And in my believe it should be 5 2 3 1 6 7 8 4 9 This was function well in R 2.7.2 Good luck, From ripley at stats.ox.ac.uk Mon Nov 3 09:51:28 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 3 Nov 2008 08:51:28 +0000 (GMT) Subject: [Rd] sort returns a wrong index (PR#13242) In-Reply-To: <20081103071507.5E6BF282EF48@mail.pubhealth.ku.dk> References: <20081103071507.5E6BF282EF48@mail.pubhealth.ku.dk> Message-ID: The default for na.last in sort() is NA (unlike sort.list): > sort.list(xd, na.last=NA) [1] 4 2 3 1 5 6 7 so the answer is correct (and the same as given by 2.7.2). On Mon, 3 Nov 2008, bert.tijhuis at wavin.com wrote: > Full_Name: Bert Tijhuis > Version: 2.8.0 > OS: MS-Windows > Submission from: (NULL) (217.140.7.52) > > >> xd > [1] 0.5 -1.0 0.2 NA -3.0 1.0 2.0 NA 2.0 > > >> sort(xd, index=T)$ix > [1] 4 2 3 1 5 6 7 > > > And in my believe it should be > 5 2 3 1 6 7 8 4 9 The FAQ asks you to report only things you 'know for certain', not beliefs. > This was function well in R 2.7.2 Indeed it did and gave the same answer as 2.8.0! -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Mon Nov 3 13:41:34 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 3 Nov 2008 12:41:34 +0000 (GMT) Subject: [Rd] row.names(data.frame(matrixWithDimnames)) depends on first rowname being "" or not. (PR#13230) In-Reply-To: <20081030040007.CCD11282EFC1@mail.pubhealth.ku.dk> References: <20081030040007.CCD11282EFC1@mail.pubhealth.ku.dk> Message-ID: On Thu, 30 Oct 2008, wdunlap at tibco.com wrote: > Full_Name: Bill Dunlap > Version: R version 2.9.0 Under development (unstable) (2008-10-29 r46795) > OS: Linux > Submission from: (NULL) (76.28.245.14) > > > When data.frame() is given a matrix with rownames, then the type of the output > row names depends on whether the first element of the input row names is "" or > not. The other elements of the input row names don't affect things. E.g., > >> data.frame(matrix(1:6, nrow=3, ncol=2, dimnames=list(c("","Row 2","Row 3"), > paste("Col",1:2)))) > Col.1 Col.2 > 1 1 4 > 2 2 5 > 3 3 6 >> data.frame(matrix(1:6, nrow=3, ncol=2, dimnames=list(c("Row 1","","Row 3"), > paste("Col",1:2)))) > Col.1 Col.2 > Row 1 1 4 > 2 5 > Row 3 3 6 > > I noticed this when converting a table of word counts (by speaker) into a > data.frame and the word "" came first in the collating sequence so the words did > not become the row names of the output. If the "" was not first in the table > then the row names of the input were carried into the output. > > I haven't had the time yet to make a fix for this, but the distinction between > row.names[1] != or == "" comes from code in data.frame() itself (not > as.data.frame.matrix): > > 81 if (missing(row.names) && nrows[i] > 0L) { > 82 rowsi <- attr(xi, "row.names") > 83 if (!(rowsi[[1L]] %in% "")) > 84 row.names <- data.row.names(row.names, rowsi, > 85 i) > 86 } > > Why is that check there? Well, there is a comment in the sources, if(missing(row.names) && nrows[i] > 0L) { rowsi <- attr(xi, "row.names") ## old way to mark optional names if(!(rowsi[[1L]] %in% "")) row.names <- data.row.names(row.names, rowsi, i) } which was last changed in Dec 2006. However, the behaviour was much older. It seems we can now change it to just test for some non-empty row name. > > Bill Dunlap > TIBCO Spotfire > wdunlap tibco.com > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Mon Nov 3 13:45:07 2008 From: ripley at stats.ox.ac.uk (ripley at stats.ox.ac.uk) Date: Mon, 3 Nov 2008 13:45:07 +0100 (CET) Subject: [Rd] row.names(data.frame(matrixWithDimnames)) depends on first (PR#13244) Message-ID: <20081103124507.B6EEC282EFC2@mail.pubhealth.ku.dk> On Thu, 30 Oct 2008, wdunlap at tibco.com wrote: > Full_Name: Bill Dunlap > Version: R version 2.9.0 Under development (unstable) (2008-10-29 r46795) > OS: Linux > Submission from: (NULL) (76.28.245.14) > > > When data.frame() is given a matrix with rownames, then the type of the output > row names depends on whether the first element of the input row names is "" or > not. The other elements of the input row names don't affect things. E.g., > >> data.frame(matrix(1:6, nrow=3, ncol=2, dimnames=list(c("","Row 2","Row 3"), > paste("Col",1:2)))) > Col.1 Col.2 > 1 1 4 > 2 2 5 > 3 3 6 >> data.frame(matrix(1:6, nrow=3, ncol=2, dimnames=list(c("Row 1","","Row 3"), > paste("Col",1:2)))) > Col.1 Col.2 > Row 1 1 4 > 2 5 > Row 3 3 6 > > I noticed this when converting a table of word counts (by speaker) into a > data.frame and the word "" came first in the collating sequence so the words did > not become the row names of the output. If the "" was not first in the table > then the row names of the input were carried into the output. > > I haven't had the time yet to make a fix for this, but the distinction between > row.names[1] != or == "" comes from code in data.frame() itself (not > as.data.frame.matrix): > > 81 if (missing(row.names) && nrows[i] > 0L) { > 82 rowsi <- attr(xi, "row.names") > 83 if (!(rowsi[[1L]] %in% "")) > 84 row.names <- data.row.names(row.names, rowsi, > 85 i) > 86 } > > Why is that check there? Well, there is a comment in the sources, if(missing(row.names) && nrows[i] > 0L) { rowsi <- attr(xi, "row.names") ## old way to mark optional names if(!(rowsi[[1L]] %in% "")) row.names <- data.row.names(row.names, rowsi, i) } which was last changed in Dec 2006. However, the behaviour was much older. It seems we can now change it to just test for some non-empty row name. > > Bill Dunlap > TIBCO Spotfire > wdunlap tibco.com > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From armstrong.whit at gmail.com Mon Nov 3 15:08:10 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Mon, 3 Nov 2008 09:08:10 -0500 Subject: [Rd] R 2.8.0 qqnorm produces error with object of class zoo? In-Reply-To: <971536df0810230416g4c12a6f1obaf8d68e77cc0c73@mail.gmail.com> References: <48FF215E.80807@biostat.ku.dk> <971536df0810220933l6be9989aie61bd69c7978bd17@mail.gmail.com> <48FF6256.8080702@biostat.ku.dk> <971536df0810221119k1709874fl309a83ad41e246c4@mail.gmail.com> <971536df0810221209x67e67bf2l1ed16e2a612db863@mail.gmail.com> <48FF952C.3040809@biostat.ku.dk> <971536df0810221735r475f4b06s40354351ea4fae05@mail.gmail.com> <971536df0810230416g4c12a6f1obaf8d68e77cc0c73@mail.gmail.com> Message-ID: <8ec76080811030608v17826822p72e68d8656f28f86@mail.gmail.com> sorry, for joining this thread so late. I've just upgraded to R2.8.0 and was hit with the same issue immediately in my fts package. Has any consensus been reached about how to deal with this issue? Do I understand correctly that the change to use: [sort.c: 592] PROTECT(call = lang4(install(".gt"), x, si, sj)); c = asInteger(eval(call, rho)); inside of "static int equal(int i, int j, SEXP x, Rboolean nalast, SEXP rho)" was to promote class based object dispatching for comparisons? -Whit On Thu, Oct 23, 2008 at 6:16 AM, Gabor Grothendieck wrote: > Based on the quote that Peter gave: > > o New generic function xtfrm() as an auxiliary helper for > sort(), order() and rank(). This should return a numeric > vector that sorts in the same way as its input. The default > method supports any class with ==, > and is.na() methods but > specific methods can be much faster. > > As a side-effect, rank() will now work better on classed > objects, although possibly rather slowly. > > it seems that it was the intention to have rank(x) use x only via xtfrm(x) > but that is not, in fact, how it works as defining xtfrm.zoo still > results in the > discussed error. > > On Thu, Oct 23, 2008 at 5:13 AM, Pfaff, Bernhard Dr. > wrote: >> Dear Achim, Gabor, Jeff, Peter and remaining list-subscribers, >> >> first, please accept my apologies for having started this thread. Given the avalanche of responses (some off-list) and the associated time stamps, some of you have almost pulled an all-nighter about this topic. I might have not have started this thread in the first place, if I would have known this. >> >> I agree with Achim's view that a "not working for zoo objects" strategy is preferable compared to a "half-working for zoo objects" strategy. I do not have either a problem by employing coredata(z) when necessary. Now, Gabor, you pointed out nicely that the culprit, namely that order() resides on top of xtfrm whereas rank() does not (this was voiced by you in an email to Peter and R-Devel, hence I inlucde these recipients again in this thread and the reason for doing this is also motivated by the following proposition): >> >> You further pointed out that the problems wrt to rank and zoo-objects could be solved if rank() would, like order() does, reside on top of xtfrm. My question/proposal would then be to follow this approach, i.e. use xtfrm in rank. Now, I am not that deep into R nor an expert to judge whether this would cause problems/breaking existing R code in other instances; hence I appreciate feedback if this would be a feasible/desirable change in R-Devel. >> >> >> Best, >> Bernhard >> >>>-----Urspr?ngliche Nachricht----- >>>Von: Gabor Grothendieck [mailto:ggrothendieck at gmail.com] >>>Gesendet: Donnerstag, 23. Oktober 2008 02:36 >>>An: Peter Dalgaard >>>Cc: Pfaff, Bernhard Dr.; r-devel at stat.math.ethz.ch >>>Betreff: Re: [Rd] R 2.8.0 qqnorm produces error with object of >>>class zoo? >>> >>>I don't think its hopeless. order works ok provided the >>>underlying class >>>defines an xtfrm method. I think rank should follow that >>>route too. Its >>>arguably the inconsistency between rank and order (order but not the >>>rank uses xtfrm) that causes the inconsistent behavior between the two. >>>If rank were also built on top of xtfrm then it would work as >>>desired as >>>well. >>> >>>On Wed, Oct 22, 2008 at 5:03 PM, Peter Dalgaard >>> wrote: >>>> Gabor Grothendieck wrote: >>>>> >>>>> And one other point. >>>>> >>>>> z <- zoo(1:4) >>>>> .gt(z, 1, 2) >>>>> >>>>> fails because z[1] and z[2] are at different time points so >>>>> >>>>> z[1] == z[2] >>>>> >>>>> is logical(0) because when zoo compares objects it aligns them >>>>> first. >>>> >>>> Yes, that was the point that I was trying to make. Well, >>>arguably it doesn't >>>> "fail", it just does what it is supposed to do. Things would >>>"work" with [[ >>>> or a preceding unclass(z), but that would break comparisons >>>involving, say, >>>> POSIXlt objects. So you're sort of stuck between a rock and >>>a hard place. >>>> >>>>> >>>>> On Wed, Oct 22, 2008 at 2:19 PM, Gabor Grothendieck >>>>> wrote: >>>>>> >>>>>> Yes, I noticed that but rank is not generic. An xtfrm.zoo >>>>>> method has been added to zoo on R-Forge but rank still >>>>>> fails: >>>>>> >>>>>>> R.version.string >>>>>> >>>>>> [1] "R version 2.8.0 Patched (2008-10-21 r46766)" >>>>>>> >>>>>>> packageDescription("zoo")$Version >>>>>> >>>>>> [1] "1.5-3" >>>>>>> >>>>>>> library(zoo) >>>>>>> # next line adds xtfrm zoo method >>>>>>> xtfrm.zoo <- coredata >>>>>>> z <- zoo(1:4) >>>>>>> order(z) # ok >>>>>> >>>>>> [1] 1 2 3 4 >>>>>>> >>>>>>> qqnorm(z) # ok >>>>>>> rank(z) # error >>>>>> >>>>>> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L : >>>>>> argument is of length zero >>>>>> >>>>>> >>>>>>>>> (If the MIME type is wrong, then that will happen.) >>>>>>>>> >>>>>>>>> Anyways, the root cause seems to be the new function >>>.gt() which is >>>>>>>>> related to >>>>>>>>> >>>>>>>>> o New generic function xtfrm() as an auxiliary helper for >>>>>>>>> sort(), order() and rank(). This should return a numeric >>>>>>>>> vector that sorts in the same way as its input. >>>The default >>>>>>>>> method supports any class with ==, > and is.na() >>>methods but >>>>>>>>> specific methods can be much faster. >>>>>>>>> >>>>>>>>> As a side-effect, rank() will now work better on classed >>>>>>>>> objects, although possibly rather slowly. >>>>>>>>> >>>>>>>>> Here, "better" may be in the eyes of the beholder, for >>>>>>>>> >>>>>>>>> >>>>>>>>>> dax[3]==dax[6] >>>>>>>>>> >>>>>>>>> Data: >>>>>>>>> logical(0) >>>>>>>>> >>>>>>>>> Index: >>>>>>>>> integer(0) >>>>>>>>> >>>>>>>>> and accordingly >>>>>>>>> >>>>>>>>> >>>>>>>>>> rank(dax) >>>>>>>>>> >>>>>>>>> Error in if (xi == xj) 0L else if (xi > xj) 1L else -1L : >>>>>>>>> argument is of length zero >>>>>>>>> >>>>>>>>> which is the error that you are seeing. >>>>>>>>> >>>>>>>>> What to do about it is a bit dubious. Obviously, we >>>don't want to >>>>>>>>> "fix" >>>>>>>>> .gt() so that it automatically unclasses objects, and I >>>assume that >>>>>>>>> zoo >>>>>>>>> has its reasons for not wanting to compare series with different >>>>>>>>> indices. So I suppose that either the user must >>>unclass, or zoo define >>>>>>>>> rank.zoo. >>>>>>>>> >>>>>>>> Actually qqnorm does not use rank but it does use order >>>and with the >>>>>>>> xtfrm.zoo method I mentioned qqnorm works with zoo; >>>however, I think >>>>>>>> rank needs to be fixed in R to make use of xtfrm as well >>>since I would >>>>>>>> have >>>>>>>> expected that supplying an xtfrm method for zoo would be >>>sufficient to >>>>>>>> get both order and rank to work without giving errors. >>>Also note that >>>>>>>> rank >>>>>>>> is not generic. >>>>>>>> >>>>>>> Notice that xtfrm.default() uses rank().... >>>>>>> >>>>>>> -- >>>>>>> O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B >>>>>>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K >>>>>>> (*) \(*) -- University of Copenhagen Denmark Ph: >>>(+45) 35327918 >>>>>>> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: >>>(+45) 35327907 >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>>> -- >>>> O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B >>>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K >>>> (*) \(*) -- University of Copenhagen Denmark Ph: >>>(+45) 35327918 >>>> ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: >>>(+45) 35327907 >>>> >>> >> ***************************************************************** >> Confidentiality Note: The information contained in this message, >> and any attachments, may contain confidential and/or privileged >> material. It is intended solely for the person(s) or entity to >> which it is addressed. Any review, retransmission, dissemination, >> or taking of any action in reliance upon this information by >> persons or entities other than the intended recipient(s) is >> prohibited. If you received this in error, please contact the >> sender and delete the material from any computer. >> ***************************************************************** >> >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From mike.prager at noaa.gov Mon Nov 3 17:11:03 2008 From: mike.prager at noaa.gov (Mike Prager) Date: Mon, 03 Nov 2008 11:11:03 -0500 Subject: [Rd] gfortran optimization problems References: <490251F3.6050301@montana.edu> Message-ID: Dave Roberts wrote: > I have a routine in package labdsv that calls a FORTRAN subroutine. > Recently, I was informed that it sometimes gives different results on a > PC and Mac, and that the PC version is clearly wrong. I tested it on > linux (because I don't have a PC), and I get the same (incorrect) > behavior as the PC. > > Simply by inserting debug WRITE statements in the FORTRAN I would get > different, and correct, results, so I assumed it was an optimization > error. > >[...] Not to prejudge the case, but such sometime errors are classic symptoms of access violations in Fortran, such as accessing a variable whose value has not been set, exceeding array bounds, or something similar. The usual suggestion is to recompile the Fortran with ALL error-checking options turned on and see if such a bug turns up. -- Mike Prager, NOAA, Beaufort, NC * Opinions expressed are personal and not represented otherwise. * Any use of tradenames does not constitute a NOAA endorsement. From pgilbert at bank-banque-canada.ca Mon Nov 3 17:36:20 2008 From: pgilbert at bank-banque-canada.ca (Paul Gilbert) Date: Mon, 03 Nov 2008 11:36:20 -0500 Subject: [Rd] R CMD check with Matlab and perl? In-Reply-To: <490DE617.40104@pdf.com> References: <490DE617.40104@pdf.com> Message-ID: <490F2884.1050301@bank-banque-canada.ca> Spencer I do something a bit like this using make, and some "R like" directory organization, to do "unit testing" of code for installing/checking databases. The tests/ and an examples/ directory I added are fairly straightforward. The fancier R things, like parsing examples out of Rd files, and checking that documented arguments correspond to code, are not so easy. I think most of this fancy stuff is very specific to the R package context, but it would be useful to think about how much of it could be generalized. Let me know if you want more detail on my test setup. Paul Spencer Graves wrote: > Hi, All: > How might one test Matlab and perl code during "R CMD check"? > I ask for two reasons: First, the "fda" package exists in both R > and Matlab, and it would help if we could run test examples in Matlab as > part of "R CMD check". I tried "R.matlab", but could not get it to work > in that context. > Second, I have professional colleagues who write code in Matlab and > perl, but have no unit or regression testing. If I could test Matlab > and perl from within "R CMD check" examples, I think I could get them to > use it, because it would produce more "trustworthy software" [the "Prime > Directive" of Chambers (2008) Software for Data Analysis (Springer)] AND > give them documentation at the same time -- while simultaneously > reducing the cost of producing and maintaining code to given > specifications. > > Thanks, > Spencer > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ==================================================================================== La version fran?aise suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. ------------------------------------------------------------------------------------ Le pr?sent courriel peut contenir de l'information privil?gi?e ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires d?sign?s est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer sans d?lai ? l'exp?diteur un message ?lectronique pour l'aviser que vous avez ?limin? de votre ordinateur toute copie du courriel re?u. From spencer.graves at pdf.com Mon Nov 3 18:03:10 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Mon, 03 Nov 2008 09:03:10 -0800 Subject: [Rd] R CMD check with Matlab and perl? In-Reply-To: <490F2884.1050301@bank-banque-canada.ca> References: <490DE617.40104@pdf.com> <490F2884.1050301@bank-banque-canada.ca> Message-ID: <490F2ECE.6090904@pdf.com> Dear Paul: Paul Gilbert wrote: > Spencer > > I do something a bit like this using make, and some "R like" directory > organization, to do "unit testing" of code for installing/checking > databases. The tests/ and an examples/ directory I added are fairly > straightforward. The fancier R things, like parsing examples out of Rd > files, and checking that documented arguments correspond to code, are > not so easy. > > I think most of this fancy stuff is very specific to the R package > context, but it would be useful to think about how much of it could be > generalized. Let me know if you want more detail on my test setup. Yes, I would like more detail. Only yesterday, I was reviewing your article in R News on "R Package Maintenance". I could study that and your comments here more carefully. However, it would help to have a bit more detail on how you make this work. Thanks very much. Spencer > > Paul > > > Spencer Graves wrote: >> Hi, All: >> How might one test Matlab and perl code during "R CMD check"? >> I ask for two reasons: First, the "fda" package exists in both >> R and Matlab, and it would help if we could run test examples in >> Matlab as part of "R CMD check". I tried "R.matlab", but could not >> get it to work in that context. >> Second, I have professional colleagues who write code in Matlab >> and perl, but have no unit or regression testing. If I could test >> Matlab and perl from within "R CMD check" examples, I think I could >> get them to use it, because it would produce more "trustworthy >> software" [the "Prime Directive" of Chambers (2008) Software for Data >> Analysis (Springer)] AND give them documentation at the same time -- >> while simultaneously reducing the cost of producing and maintaining >> code to given specifications. >> >> Thanks, >> Spencer >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > ==================================================================================== > > > La version fran?aise suit le texte anglais. > > ------------------------------------------------------------------------------------ > > > This email may contain privileged and/or confidential information, and > the Bank of > Canada does not waive any related rights. Any distribution, use, or > copying of this > email or the information it contains by other than the intended > recipient is > unauthorized. If you received this email in error please delete it > immediately from > your system and notify the sender promptly by email that you have done > so. > ------------------------------------------------------------------------------------ > > > Le pr?sent courriel peut contenir de l'information privil?gi?e ou > confidentielle. > La Banque du Canada ne renonce pas aux droits qui s'y rapportent. > Toute diffusion, > utilisation ou copie de ce courriel ou des renseignements qu'il > contient par une > personne autre que le ou les destinataires d?sign?s est interdite. Si > vous recevez > ce courriel par erreur, veuillez le supprimer imm?diatement et envoyer > sans d?lai ? > l'exp?diteur un message ?lectronique pour l'aviser que vous avez > ?limin? de votre > ordinateur toute copie du courriel re?u. From renger at ecoplan.ch Mon Nov 3 10:00:04 2008 From: renger at ecoplan.ch (renger at ecoplan.ch) Date: Mon, 3 Nov 2008 10:00:04 +0100 (CET) Subject: [Rd] Bug in Version 2.80? (PR#13243) Message-ID: <20081103090004.8D3EB283460B@mail.pubhealth.ku.dk> Hi When I have a plot under Windows and want to save it as a ps or jpg using right click, the window for choosing the directory opens. But if I want to choose a directory R freezes. This happens on my XP notebook as well on my P x64 machine. Renger _______________________ Renger van Nieuwkoop=20 Ecoplan - Thunstrasse 22=20 3005 Bern Switzerland=20 Tel. +41 31 356 61 61 Mail: renger at ecoplan.ch=20 _______________________ [[alternative HTML version deleted]] From voyager1983 at 163.com Mon Nov 3 14:03:04 2008 From: voyager1983 at 163.com (=?gbk?B?zfXTwNbH?=) Date: Mon, 3 Nov 2008 21:03:04 +0800 (CST) Subject: [Rd] A question about the API mkchar() In-Reply-To: References: Message-ID: <30848992.562331225717384985.JavaMail.coremail@bj163app81.163.com> Hi, Simon Thanks for your elaborated instruction on mkCharCE. Concerning the UTF-8 Encoding, mkCharCE(X, CE_UTF8) is the correct way in parsing the Unicode string. However, I met another question: My program logic is intended to read the content of a text file r.tmp, which is encoded with UTF-8. After reading it, every line will be send to another C function ext_show(t const char** text, int* length, int* errLevel) for the further handle. Attached is the text file ?r.tmp?. I tried to use the following R code to accomplish the process: checkoutput<-scan(?r.tmp?, what='character', blank.lines.skip=FALSE, sep='\n', skip=0, quiet=TRUE, encoding = ?unknown?) lines<-length(checkoutput) print(checkoutput) for (i in 1:lines) { Inputstring = checkoutput[i] out <- .C('ext_show',as.character(inputstring), as.integer(nchar(inputstring)), as.integer(err), PACKAGE="mypkg") } I don?t know why, if I typed the command in R GUI environment, the Japanese character can be shown correctly. Also, if I sink the inputstring into another text file, the content of this file also written correctly. But if I use the above code passing the inputstring into function ext_show, the string passed inputstring has been changed in the function ext_show (). My current environment is WindowsXP, R 2.7.0, R encoding is "UTF-8": > getOption("encoding") [1] "UTF-8" > Sys.getlocale() [1] "LC_COLLATE=Chinese_People's Republic of China.936;LC_CTYPE=Chinese_People's Republic of China.936;LC_MONETARY=Chinese_People's Republic of China.936;LC_NUMERIC=C;LC_TIME=Chinese_People's Republic of China.936" For current encoding is UTF-8, I don't think Chinese local will hinder the correct result. The ext_show is defined as below: void ext_show( const char** text, int* length, int* errLevel) { *errLevel = LoadLib(); int real_length = strlen(*text); if( LOAD_SUCCESS == *errLevel ) *errLevel = ShowInScreen(*text, real_length); } I am new to the R programming, and not every familiar with the encoding handle in R, I suspect if it is necessary to convert encoding of the inputstring before passing to the function ext_show(). Many Thanks! Joey ?2008-10-28?"Simon Urbanek" ??? >On Oct 28, 2008, at 6:26 , F?n L?ng wrote: > >> Hi guys, >> > >Hey guy :) > > >> I've got a question about the API mkchar(). I have met some >> difficulty in parsing utf-8 string to mkchar() in R-2.7.0. >> > >There is no mkchar() in R. Did you perhaps mean mkChar()? > > >> I was intending to parse an utf-8 string str_jan (some Japanese >> characters such as?, whose utf-8 code is E381B5 > >There is no such "UTF-8" code. I'm not sure if you meant Unicode, but >that would be \u3075 (Hiragana hu) for that character. The UTF-8 >encoding of that character is a three-byte sequence 0xe3 0x81 0xb5 if >that's what you meant. > > >> ) to R API SEXP >> mkChar(const char *name) , we only need to create the SEXP using the >> string that we parsed. >> >> >> >> Unfortunately, I found when parsing the variable str_jan, R will >> automatically convert the str_jan according to the current locale >> setting, > >That is not true - it will be kept as-is regardless of the encoding. >Note that mkChar(x) is equivalent to mkCharCE(x, CE_NATIVE); No >conversion takes place when the string is created, but you have told R >that it is in the native encoding. If that is not true (which is your >case probably isn't), all bets are off since you're lying to R ;). > > >> so only in the English locale could the function work correctly, >> under other locale, such as Japanese or Chinese, the string will be >> convert incorrectly. > >That is clearly a nonsense since the encoding has nothing to do with >the locale language itself (Japanese, Chinese, ..). We are talking >about the encoding (note that both English and Japanese locales can >use UTF-8 encoding, but don't have to). I think you'll need to get the >concepts right here - for each string you must define the encoding in >order to be able to reproduce the unicode sequence that the string >represents. At this point it has nothing to do with the language. > > >> As a matter of fact, those utf-8 code already is Unicode string, and >> don't need to be converted at all. >> >> I also tried to use the SEXP Rf_mkCharCE(const char *, cetype_t);, >> Parsing the CE_UTF8 as the argument of cetype_t, but the result is >> worse. It returned the result as ucs code, an kind of Unicode under >> windows platform. >> > >Well, that's exactly what you want, isn't it? The string is correctly >flagged as UTF-8 so R is finally able to find out what exactly is >represented by that string. However, your locale apparently doesn't >support such characters so it cannot be displayed. If you use a locale >that supports it, it works just fine, for example if you use local >with SJIS encoding R will still know how to convert it from UTF-8 to >SJIS *for display*. The actual string is not touched. > >Here is a small piece of code that shows you the difference between >native encoding and UTF8-strings: > >#include >#include > >SEXP me() { > const char c[] = { 0xe3, 0x81, 0xb5, 0 }; > SEXP a = allocVector(STRSXP, 2); > PROTECT(a); > SET_STRING_ELT(a, 0, mkCharCE(c, CE_NATIVE)); > SET_STRING_ELT(a, 1, mkCharCE(c, CE_UTF8)); > UNPROTECT(1); > return a; >} > >In a UTF-8 locale it doesn't matter: > >ginaz:sandbox$ LANG=ja_JP.UTF-8 R > > .Call("me") >[1] "?" "?" > >But in any other, let's say SJIS, it does: > >ginaz:sandbox$ LANG=ja_JP.SJIS R > > .Call("me") >[1] "??" "?" > >Note that the first string is wrong, because we have supplied UTF-8 >encoding but the current one is SJIS. The second one is correct since >we told R that it's UTF-8 encoded. > >Finally, if the character cannot be displayed in the given encoding: > >ginaz:sandbox$ LANG=en_US.US-ASCII R > > .Call("me") >[1] "\343\201\265" " From ripley at stats.ox.ac.uk Mon Nov 3 22:07:40 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 3 Nov 2008 21:07:40 +0000 (GMT) Subject: [Rd] A question about the API mkchar() In-Reply-To: <30848992.562331225717384985.JavaMail.coremail@bj163app81.163.com> References: <30848992.562331225717384985.JavaMail.coremail@bj163app81.163.com> Message-ID: 1) 2.7.0 is rather old, and you were asked to update your R before posting. 2) No file was attached. But how to handle encodings is in the 'R Internals' manual. This is a tricky, advanced, topic in C-level R programming. It is your responsibility, not ours, to get yourself up to the level of understanding required. Sorry, but it is not reasonable to expect a personal tutorial in this forum. On Mon, 3 Nov 2008, ??? wrote: > Hi, Simon > > > Thanks for your elaborated instruction on mkCharCE. > > Concerning the UTF-8 Encoding, mkCharCE(X, CE_UTF8) is the correct way in parsing the Unicode string. > > However, I met another question: > > My program logic is intended to read the content of a text file r.tmp, which is encoded with UTF-8. After reading it, every line will be send to another C function ext_show(t const char** text, int* length, int* errLevel) for the further handle. Attached is the text file ?r.tmp?. > > I tried to use the following R code to accomplish the process: > > checkoutput<-scan(?r.tmp?, > > what='character', > > blank.lines.skip=FALSE, > > sep='\n', > > skip=0, > > quiet=TRUE, > > encoding = ?unknown?) > > lines<-length(checkoutput) > > print(checkoutput) > > for (i in 1:lines) > > { > > Inputstring = checkoutput[i] > > out <- .C('ext_show',as.character(inputstring), > > as.integer(nchar(inputstring)), > > as.integer(err), > > PACKAGE="mypkg") > > } > > > > > > I don?t know why, if I typed the command in R GUI environment, the Japanese character can be shown correctly. Also, if I sink the inputstring into another text file, the content of this file also written correctly. > > But if I use the above code passing the inputstring into function ext_show, the string passed inputstring has been changed in the function ext_show (). > > My current environment is WindowsXP, R 2.7.0, R encoding is "UTF-8": > >> getOption("encoding") > [1] "UTF-8" > >> Sys.getlocale() > [1] "LC_COLLATE=Chinese_People's Republic of China.936;LC_CTYPE=Chinese_People's Republic of China.936;LC_MONETARY=Chinese_People's Republic of China.936;LC_NUMERIC=C;LC_TIME=Chinese_People's Republic of China.936" > > > For current encoding is UTF-8, I don't think Chinese local will hinder the correct result. > > The ext_show is defined as below: > > void ext_show( > > const char** text, > > int* length, > > int* errLevel) > > { > > *errLevel = LoadLib(); > > int real_length = strlen(*text); > > if( LOAD_SUCCESS == *errLevel ) > > *errLevel = ShowInScreen(*text, real_length); > > } > > I am new to the R programming, and not every familiar with the encoding handle in R, I suspect if it is necessary to convert encoding of the inputstring before passing to the function ext_show(). > > Many Thanks! > > Joey > > > ?2008-10-28?"Simon Urbanek" ??? >> On Oct 28, 2008, at 6:26 , F?n L?ng wrote: >> >>> Hi guys, >>> >> >> Hey guy :) >> >> >>> I've got a question about the API mkchar(). I have met some >>> difficulty in parsing utf-8 string to mkchar() in R-2.7.0. >>> >> >> There is no mkchar() in R. Did you perhaps mean mkChar()? >> >> >>> I was intending to parse an utf-8 string str_jan (some Japanese >>> characters such as?, whose utf-8 code is E381B5 >> >> There is no such "UTF-8" code. I'm not sure if you meant Unicode, but >> that would be \u3075 (Hiragana hu) for that character. The UTF-8 >> encoding of that character is a three-byte sequence 0xe3 0x81 0xb5 if >> that's what you meant. >> >> >>> ) to R API SEXP >>> mkChar(const char *name) , we only need to create the SEXP using the >>> string that we parsed. >>> >>> >>> >>> Unfortunately, I found when parsing the variable str_jan, R will >>> automatically convert the str_jan according to the current locale >>> setting, >> >> That is not true - it will be kept as-is regardless of the encoding. >> Note that mkChar(x) is equivalent to mkCharCE(x, CE_NATIVE); No >> conversion takes place when the string is created, but you have told R >> that it is in the native encoding. If that is not true (which is your >> case probably isn't), all bets are off since you're lying to R ;). >> >> >>> so only in the English locale could the function work correctly, >>> under other locale, such as Japanese or Chinese, the string will be >>> convert incorrectly. >> >> That is clearly a nonsense since the encoding has nothing to do with >> the locale language itself (Japanese, Chinese, ..). We are talking >> about the encoding (note that both English and Japanese locales can >> use UTF-8 encoding, but don't have to). I think you'll need to get the >> concepts right here - for each string you must define the encoding in >> order to be able to reproduce the unicode sequence that the string >> represents. At this point it has nothing to do with the language. >> >> >>> As a matter of fact, those utf-8 code already is Unicode string, and >>> don't need to be converted at all. >>> >>> I also tried to use the SEXP Rf_mkCharCE(const char *, cetype_t);, >>> Parsing the CE_UTF8 as the argument of cetype_t, but the result is >>> worse. It returned the result as ucs code, an kind of Unicode under >>> windows platform. >>> >> >> Well, that's exactly what you want, isn't it? The string is correctly >> flagged as UTF-8 so R is finally able to find out what exactly is >> represented by that string. However, your locale apparently doesn't >> support such characters so it cannot be displayed. If you use a locale >> that supports it, it works just fine, for example if you use local >> with SJIS encoding R will still know how to convert it from UTF-8 to >> SJIS *for display*. The actual string is not touched. >> >> Here is a small piece of code that shows you the difference between >> native encoding and UTF8-strings: >> >> #include >> #include >> >> SEXP me() { >> const char c[] = { 0xe3, 0x81, 0xb5, 0 }; >> SEXP a = allocVector(STRSXP, 2); >> PROTECT(a); >> SET_STRING_ELT(a, 0, mkCharCE(c, CE_NATIVE)); >> SET_STRING_ELT(a, 1, mkCharCE(c, CE_UTF8)); >> UNPROTECT(1); >> return a; >> } >> >> In a UTF-8 locale it doesn't matter: >> >> ginaz:sandbox$ LANG=ja_JP.UTF-8 R >>> .Call("me") >> [1] "?" "?" >> >> But in any other, let's say SJIS, it does: >> >> ginaz:sandbox$ LANG=ja_JP.SJIS R >>> .Call("me") >> [1] "??" "?" >> >> Note that the first string is wrong, because we have supplied UTF-8 >> encoding but the current one is SJIS. The second one is correct since >> we told R that it's UTF-8 encoded. >> >> Finally, if the character cannot be displayed in the given encoding: >> >> ginaz:sandbox$ LANG=en_US.US-ASCII R >>> .Call("me") >> [1] "\343\201\265" " -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From jfox at mcmaster.ca Mon Nov 3 22:33:34 2008 From: jfox at mcmaster.ca (John Fox) Date: Mon, 3 Nov 2008 16:33:34 -0500 Subject: [Rd] possible tcltk event loop problem Message-ID: <008201c93dfb$d336f650$79a4e2f0$@ca> Dear list members, Rich Heiberger reported to me last week that the Messages window in the Rcmdr GUI was freezing -- that is, messages posted to this window didn't appear -- under Windows and R 2.8.0. I was able to confirm this problem on three Windows systems, one using Vista and the other two XP. In each case, I used R 2.8.0 and Rcmdr 1.4-4 (the current version). The problem doesn't occur with R 2.7.2 and Rcmdr 1.4-4. Nor does it occur on my Mac OS/X and Ubtuntu Linux systems. In my case, the problem occurred only using Rgui, not under Rterm. Rich experienced the problem with both Rgui and Rterm. On the other hand, Erich Neuwirth tells me that the Messages window works fine for him generally under Windows with R 2.8.0 and Rcmdr 1.4-4, so whatever the source of the problem, it doesn't always manifest itself. Some detail, and a kludgy solution appear below. What's odd is that the Rcmdr has three similar windows -- Script, Output, and Messages, created by the following code: For the messages window: messagesFrame <- tkframe(.commander) putRcmdr("messagesWindow", tktext(messagesFrame, bg="lightgray", font=getRcmdr("logFont"), height=3, width=log.width, wrap="none")) .messages <- MessagesWindow() messagesXscroll <- ttkscrollbar(messagesFrame, orient="horizontal", command=function(...) tkxview(.messages, ...)) messagesYscroll <- ttkscrollbar(messagesFrame, command=function(...) tkyview(.messages, ...)) tkconfigure(.messages, xscrollcommand=function(...) tkset(messagesXscroll, ...)) tkconfigure(.messages, yscrollcommand=function(...) tkset(messagesYscroll, ...)) For the script window (note that "log" is a hold-over from earlier terminology): logFrame <- tkframe(CommanderWindow()) putRcmdr("logWindow", tktext(logFrame, bg="white", foreground=getRcmdr("log.text.color"), font=getRcmdr("logFont"), height=log.height, width=log.width, wrap="none", undo=TRUE)) .log <- LogWindow() logXscroll <- ttkscrollbar(logFrame, orient="horizontal", command=function(...) tkxview(.log, ...)) logYscroll <- ttkscrollbar(logFrame, command=function(...) tkyview(.log, ...)) tkconfigure(.log, xscrollcommand=function(...) tkset(logXscroll, ...)) tkconfigure(.log, yscrollcommand=function(...) tkset(logYscroll, ...)) For the output window: outputFrame <- tkframe(.commander) putRcmdr("outputWindow", tktext(outputFrame, bg="white", foreground=getRcmdr("output.text.color"), font=getRcmdr("logFont"), height=output.height, width=log.width, wrap="none", undo=TRUE)) .output <- OutputWindow() outputXscroll <- ttkscrollbar(outputFrame, orient="horizontal", command=function(...) tkxview(.output, ...)) outputYscroll <- ttkscrollbar(outputFrame, command=function(...) tkyview(.output, ...)) tkconfigure(.output, xscrollcommand=function(...) tkset(outputXscroll, ...)) tkconfigure(.output, yscrollcommand=function(...) tkset(outputYscroll, ...)) Note that the functions MessagesWindow(), LogWindow(), and OutputWindow() simply return their respective tk windows. These windows are also similarly placed in the master Rcmdr window (slightly edited): tkgrid(.log, logYscroll, sticky="news", columnspan=2) tkgrid(logXscroll) tkgrid(logFrame, sticky="news", padx=10, pady=0, columnspan=2) tkgrid(.output, outputYscroll, sticky="news", columnspan=2) tkgrid(outputXscroll, columnspan=1 + (.log.commands && !.console.output)) tkgrid(outputFrame, sticky="news", padx=10, pady=0, columnspan=2) tkgrid(.messages, messagesYscroll, sticky="news", columnspan=2) tkgrid(messagesXscroll) tkgrid(messagesFrame, sticky="news", padx=10, pady=0, columnspan=2) I was able successfully to write directly to the script and output windows: > tkinsert(LogWindow(), "end", "\n testing \n") > tkinsert(OutputWindow(), "end", "\n testing \n") But writing to the message window, though it produced no error, also had no visible effect: > tkinsert(MessagesWindow(), "end", "\n testing \n") Checking the contents of the Messages window via tkget(MessagesWindow(), "1.0", "end") revealed, however, that the text should have been there. Suspecting a timing/event-loop-synchronization issue, I inserted a delay into the function that sends text to the Messages window; here's a simplified version of that function: Message <- function(message, type=c("note", "error", "warning")){ Sys.sleep(0.01) .message <- MessagesWindow() if (!missing(message)) { tkinsert(.message, "end", paste("\n", message, "\n")) tkyview.moveto(.message, 1.0) } } The 0.01 second delay is apparently sufficient to fix the problem. I'm reporting the problem because I suspect that there's some issue with tcltk in the Windows version of R 2.8.0 (though I didn't see anything in the CHANGES or NEWS file to suggest this). Regards, John ------------------------------ John Fox, Professor Department of Sociology McMaster University Hamilton, Ontario, Canada web: socserv.mcmaster.ca/jfox From p.dalgaard at biostat.ku.dk Mon Nov 3 22:58:01 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Mon, 03 Nov 2008 22:58:01 +0100 Subject: [Rd] possible tcltk event loop problem In-Reply-To: <008201c93dfb$d336f650$79a4e2f0$@ca> References: <008201c93dfb$d336f650$79a4e2f0$@ca> Message-ID: <490F73E9.1030706@biostat.ku.dk> John Fox wrote: > Dear list members, > > Rich Heiberger reported to me last week that the Messages window in the > Rcmdr GUI was freezing -- that is, messages posted to this window didn't > appear -- under Windows and R 2.8.0. I was able to confirm this problem on > three Windows systems, one using Vista and the other two XP. In each case, I > used R 2.8.0 and Rcmdr 1.4-4 (the current version). The problem doesn't > occur with R 2.7.2 and Rcmdr 1.4-4. Nor does it occur on my Mac OS/X and > Ubtuntu Linux systems. In my case, the problem occurred only using Rgui, not > under Rterm. Rich experienced the problem with both Rgui and Rterm. On the > other hand, Erich Neuwirth tells me that the Messages window works fine for > him generally under Windows with R 2.8.0 and Rcmdr 1.4-4, so whatever the > source of the problem, it doesn't always manifest itself. Some detail, and a > kludgy solution appear below. > > What's odd is that the Rcmdr has three similar windows -- Script, Output, > and Messages, created by the following code: > > For the messages window: > > messagesFrame <- tkframe(.commander) > putRcmdr("messagesWindow", tktext(messagesFrame, bg="lightgray", > font=getRcmdr("logFont"), height=3, width=log.width, wrap="none")) > .messages <- MessagesWindow() > messagesXscroll <- ttkscrollbar(messagesFrame, orient="horizontal", > command=function(...) tkxview(.messages, ...)) > messagesYscroll <- ttkscrollbar(messagesFrame, > command=function(...) tkyview(.messages, ...)) > tkconfigure(.messages, xscrollcommand=function(...) > tkset(messagesXscroll, ...)) > tkconfigure(.messages, yscrollcommand=function(...) > tkset(messagesYscroll, ...)) > > For the script window (note that "log" is a hold-over from earlier > terminology): > > logFrame <- tkframe(CommanderWindow()) > putRcmdr("logWindow", tktext(logFrame, bg="white", > foreground=getRcmdr("log.text.color"), > font=getRcmdr("logFont"), height=log.height, width=log.width, > wrap="none", undo=TRUE)) > .log <- LogWindow() > logXscroll <- ttkscrollbar(logFrame, orient="horizontal", > command=function(...) tkxview(.log, ...)) > logYscroll <- ttkscrollbar(logFrame, > command=function(...) tkyview(.log, ...)) > tkconfigure(.log, xscrollcommand=function(...) tkset(logXscroll, ...)) > tkconfigure(.log, yscrollcommand=function(...) tkset(logYscroll, ...)) > > For the output window: > > outputFrame <- tkframe(.commander) > > putRcmdr("outputWindow", tktext(outputFrame, bg="white", > foreground=getRcmdr("output.text.color"), > font=getRcmdr("logFont"), height=output.height, width=log.width, > wrap="none", undo=TRUE)) > .output <- OutputWindow() > outputXscroll <- ttkscrollbar(outputFrame, orient="horizontal", > command=function(...) tkxview(.output, ...)) > outputYscroll <- ttkscrollbar(outputFrame, > command=function(...) tkyview(.output, ...)) > tkconfigure(.output, xscrollcommand=function(...) tkset(outputXscroll, > ...)) > tkconfigure(.output, yscrollcommand=function(...) tkset(outputYscroll, > ...)) > > Note that the functions MessagesWindow(), LogWindow(), and OutputWindow() > simply return their respective tk windows. > > These windows are also similarly placed in the master Rcmdr window (slightly > edited): > > tkgrid(.log, logYscroll, sticky="news", columnspan=2) > tkgrid(logXscroll) > tkgrid(logFrame, sticky="news", padx=10, pady=0, columnspan=2) > > tkgrid(.output, outputYscroll, sticky="news", columnspan=2) > tkgrid(outputXscroll, columnspan=1 + (.log.commands && > !.console.output)) > tkgrid(outputFrame, sticky="news", padx=10, pady=0, columnspan=2) > > tkgrid(.messages, messagesYscroll, sticky="news", columnspan=2) > tkgrid(messagesXscroll) > tkgrid(messagesFrame, sticky="news", padx=10, pady=0, columnspan=2) > > I was able successfully to write directly to the script and output windows: > >> tkinsert(LogWindow(), "end", "\n testing \n") > > >> tkinsert(OutputWindow(), "end", "\n testing \n") > > > But writing to the message window, though it produced no error, also had no > visible effect: > >> tkinsert(MessagesWindow(), "end", "\n testing \n") > > > Checking the contents of the Messages window via tkget(MessagesWindow(), > "1.0", "end") revealed, however, that the text should have been there. > > Suspecting a timing/event-loop-synchronization issue, I inserted a delay > into the function that sends text to the Messages window; here's a > simplified version of that function: > > Message <- function(message, type=c("note", "error", "warning")){ > Sys.sleep(0.01) > .message <- MessagesWindow() > if (!missing(message)) { > tkinsert(.message, "end", paste("\n", message, "\n")) > tkyview.moveto(.message, 1.0) > } > } > > The 0.01 second delay is apparently sufficient to fix the problem. > > I'm reporting the problem because I suspect that there's some issue with > tcltk in the Windows version of R 2.8.0 (though I didn't see anything in the > CHANGES or NEWS file to suggest this). ... Hmm, does it help with a suitably placed tcl("update") or tcl("update","idletasks")? -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From jfox at mcmaster.ca Mon Nov 3 23:39:47 2008 From: jfox at mcmaster.ca (John Fox) Date: Mon, 3 Nov 2008 17:39:47 -0500 Subject: [Rd] possible tcltk event loop problem In-Reply-To: <490F73E9.1030706@biostat.ku.dk> References: <008201c93dfb$d336f650$79a4e2f0$@ca> <490F73E9.1030706@biostat.ku.dk> Message-ID: <009801c93e05$189b4f80$49d1ee80$@ca> Dear Peter, > -----Original Message----- > From: Peter Dalgaard [mailto:p.dalgaard at biostat.ku.dk] > Sent: November-03-08 4:58 PM > To: John Fox > Cc: r-devel at r-project.org; 'Richard M. Heiberger'; 'Erich Neuwirth'; 'Prof > Brian Ripley'; 'Duncan Murdoch' > Subject: Re: [Rd] possible tcltk event loop problem > . . . > > CHANGES or NEWS file to suggest this). > ... > > Hmm, does it help with a suitably placed tcl("update") or > tcl("update","idletasks")? > Yes, both seem to cure the problem, at least on my Vista machine (which is what I just checked). I believe that I tried tcl("update","idletasks") before, but must have put it in an unhelpful place. I'll explore further and send another message if the problem persists. Thanks, John From cberry at tajo.ucsd.edu Mon Nov 3 23:40:35 2008 From: cberry at tajo.ucsd.edu (Charles C. Berry) Date: Mon, 3 Nov 2008 14:40:35 -0800 Subject: [Rd] Bug in Version 2.80? (PR#13243) In-Reply-To: <20081103090004.8D3EB283460B@mail.pubhealth.ku.dk> References: <20081103090004.8D3EB283460B@mail.pubhealth.ku.dk> Message-ID: On Mon, 3 Nov 2008, renger at ecoplan.ch wrote: > > Hi > > When I have a plot under Windows and want to save it as a ps or jpg > using right click, the window for choosing the directory opens. But if I > want to choose a directory R freezes. This happens on my XP notebook as > well on my P x64 machine. Works OK for me: > plot(1:10) > > ## right click on plot - navigate and save plot as eps > ## or use file menu and do the same > > sessionInfo() R version 2.8.0 (2008-10-20) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base This is on Windows Xp Home Edition SP 3, AMD Athlon 64 HTH, Chuck > > Renger > _______________________ > > Renger van Nieuwkoop=20 > Ecoplan - Thunstrasse 22=20 > 3005 Bern Switzerland=20 > Tel. +41 31 356 61 61 > Mail: renger at ecoplan.ch=20 > _______________________ > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Charles C. Berry (858) 534-2098 Dept of Family/Preventive Medicine E mailto:cberry at tajo.ucsd.edu UC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901 From murdoch at stats.uwo.ca Tue Nov 4 00:24:23 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Mon, 03 Nov 2008 18:24:23 -0500 Subject: [Rd] Bug in Version 2.80? (PR#13243) In-Reply-To: <20081103090004.8D3EB283460B@mail.pubhealth.ku.dk> References: <20081103090004.8D3EB283460B@mail.pubhealth.ku.dk> Message-ID: <490F8827.8040208@stats.uwo.ca> On 03/11/2008 4:00 AM, renger at ecoplan.ch wrote: > Hi > > When I have a plot under Windows and want to save it as a ps or jpg > using right click, the window for choosing the directory opens. But if I > want to choose a directory R freezes. This happens on my XP notebook as > well on my P x64 machine. I don't see a window for choosing the directory, just a dialog for entering a filename. If you leave the filename blank, the dialog won't close when you click on Save, and R won't continue until you close the dialog. That's all normal behaviour. If you're seeing something else, please post exact details on how to reproduce it starting from a blank session, and tell us what sessionInfo() reports. Duncan Murdoch > > Renger > _______________________ > > Renger van Nieuwkoop=20 > Ecoplan - Thunstrasse 22=20 > 3005 Bern Switzerland=20 > Tel. +41 31 356 61 61 > Mail: renger at ecoplan.ch=20 > _______________________ > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From ripley at stats.ox.ac.uk Tue Nov 4 16:38:26 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 4 Nov 2008 15:38:26 +0000 (GMT) Subject: [Rd] (PR#13195) Can't open files containing russian letters in path In-Reply-To: <20081022211017.B9BA6282EF48@mail.pubhealth.ku.dk> References: <20081022211017.B9BA6282EF48@mail.pubhealth.ku.dk> Message-ID: Can we please have a reproducible example, as well as all the details requested in the posting guide. There are literally tens of different ways to 'open files' in R, and some at least with Cyrillic file names. Nor is there any obvious difference between 2.8.0 and 2.7.2 patched. On Wed, 22 Oct 2008, asherman at ksu.ru wrote: > Full_Name: Arkady Sherman > Version: 2.8.0 > OS: Windows XP sp3 ntfs file system > Submission from: (NULL) (158.195.166.129) > > > Freshly installed version 2.7.2 works well, but 2.8.0 can't open files with > russian letters in its names. In error messages the letters are replaced with > different symbols. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Tue Nov 4 17:00:18 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 4 Nov 2008 16:00:18 +0000 (GMT) Subject: [Rd] (PR#13195) Can't open files containing russian letters in path In-Reply-To: References: <20081022211017.B9BA6282EF48@mail.pubhealth.ku.dk> Message-ID: On Tue, 4 Nov 2008, Prof Brian Ripley wrote: > Can we please have a reproducible example, as well as all the details > requested in the posting guide. > > There are literally tens of different ways to 'open files' in R, and some at > least with Cyrillic file names. Nor is there any obvious difference between > 2.8.0 and 2.7.2 patched. Here is one working example: > nm <- "???" > writeLines(letters, nm) > readLines(nm) [1] "a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" [20] "t" "u" "v" "w" "x" "y" "z" and the file name in Windows Explorer is indeed in Cyrillic. This even works for me in Western European Windows. So your assertion is definitely incorrect as far as file() connections are concerned. > > On Wed, 22 Oct 2008, asherman at ksu.ru wrote: > >> Full_Name: Arkady Sherman >> Version: 2.8.0 >> OS: Windows XP sp3 ntfs file system >> Submission from: (NULL) (158.195.166.129) >> >> >> Freshly installed version 2.7.2 works well, but 2.8.0 can't open files with >> russian letters in its names. In error messages the letters are replaced >> with >> different symbols. >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, ripley at stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From Alexey.Ivanov at ksu.ru Tue Nov 4 17:47:51 2008 From: Alexey.Ivanov at ksu.ru (Alexey Ivanov) Date: Tue, 4 Nov 2008 19:47:51 +0300 (MSK) Subject: [Rd] (PR#13195) Can't open files containing russian letters in path Message-ID: <1270.158.195.16.114.1225817271.squirrel@webmail.ksu.ru> Thanks for the attention. So my windows locale is Russian (Cyrillic, Win-1251). I installed R-2.8.0-win32.exe. I've got a file with Cyrillic letters in its name, for example "C:\???.txt". When I try to open it from R menu "File->Source R code ..." it produces an error: > source("C:\\666.txt") Error in file(file, "r", encoding = encoding) : cannot open the connection In addition: Warning message: In file(file, "r", encoding = encoding) : cannot open file 'C:\666.txt': No such file or directory the Cyrillic letters "???" in this case are somehow replaced with "666" Prof Brian Ripley wrote: > Can we please have a reproducible example, as well as all the details > requested in the posting guide. > > There are literally tens of different ways to 'open files' in R, and > some at least with Cyrillic file names. Nor is there any obvious > difference between 2.8.0 and 2.7.2 patched. > > On Wed, 22 Oct 2008, asherman at ksu.ru wrote: > >> Full_Name: Arkady Sherman >> Version: 2.8.0 >> OS: Windows XP sp3 ntfs file system >> Submission from: (NULL) (158.195.166.129) >> >> >> Freshly installed version 2.7.2 works well, but 2.8.0 can't open files >> with >> russian letters in its names. In error messages the letters are >> replaced with >> different symbols. >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From ripley at stats.ox.ac.uk Tue Nov 4 18:48:29 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 4 Nov 2008 17:48:29 +0000 (GMT) Subject: [Rd] (PR#13195) Can't open files containing russian letters in path In-Reply-To: <4910758F.70702@ksu.ru> References: <20081022211017.B9BA6282EF48@mail.pubhealth.ku.dk> <4910758F.70702@ksu.ru> Message-ID: Thanks, I have found the problem. It is *far* less extensive than you claimed, affecting only a couple of menu items. The problem is the C-level function consolecmd, which was passing Unicode characters to storekey. That used to be correct, but the changes made by the Japanese to incorporate their IME had inter alia broken consolecmd in non-Latin-1 single byte locales. This looks like the explanation for the vague problem reported with the script editor, which uses consolecmd to submit commands (whereas the pager does not). Note that those file choice dialog boxes are only intended to work in the native encoding, so you can only choose a file name in Russian in a Russian version of Windows. That made tracking this down more than a little tedious. On Tue, 4 Nov 2008, Alexey Ivanov wrote: > Thanks for the attention. > So my windows locale is Russian (Cyrillic, Win-1251). I installed R-2.8.0-win32.exe. I've got a > file with Cyrillic letters in its name, for example "C:\???.txt". When I try to open it from R > menu "File->Source R code ..." it produces an error: > >> source("C:\\666.txt") > Error in file(file, "r", encoding = encoding) : > cannot open the connection > In addition: Warning message: > In file(file, "r", encoding = encoding) : > cannot open file 'C:\666.txt': No such file or directory > > the Cyrillic letters "???" in this case are somehow replaced with "666" > > Prof Brian Ripley wrote: >> Can we please have a reproducible example, as well as all the details >> requested in the posting guide. >> >> There are literally tens of different ways to 'open files' in R, and >> some at least with Cyrillic file names. Nor is there any obvious >> difference between 2.8.0 and 2.7.2 patched. >> >> On Wed, 22 Oct 2008, asherman at ksu.ru wrote: >> >>> Full_Name: Arkady Sherman >>> Version: 2.8.0 >>> OS: Windows XP sp3 ntfs file system >>> Submission from: (NULL) (158.195.166.129) >>> >>> >>> Freshly installed version 2.7.2 works well, but 2.8.0 can't open files >>> with >>> russian letters in its names. In error messages the letters are >>> replaced with >>> different symbols. >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Tue Nov 4 19:08:04 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 4 Nov 2008 18:08:04 +0000 (GMT) Subject: [Rd] 2.8.0 release bugs (PR#13210) In-Reply-To: <20081028143009.7EEC5282BEBF@mail.pubhealth.ku.dk> References: <20081028143009.7EEC5282BEBF@mail.pubhealth.ku.dk> Message-ID: Regretably we have had no clarification: posting incomplete bug reports and not replyng to requests for missing basic information is really bad manners, and please do remember this is a volunteer project (and one in which those doing the work have contributed support for Central European languages out of pure altruism). At one guess as to the meaning of this, it is fixed in R-patched as from svn rev 46827. Let's hope Mr Musek recovers his manners enough to try this out and post confirmation (or not). On Tue, 28 Oct 2008, maechler at stat.math.ethz.ch wrote: > Dear Janek, > >>>>>> "jm" == janek musek >>>>>> on Mon, 27 Oct 2008 20:30:10 +0100 (CET) writes: > > jm> Dear colleagues, Using the last release 2.8.0 I had (for > jm> the first time since working with R) the difficulties in > jm> transmission of some Central European letters (=B9=F0= > jm> =E8=E6=BE) from R editor to the console and graphic > jm> window. They appear correctly in commands in R editor > jm> window, yet after executing ctrl R, they have been > jm> transformed to other codes or blanks (in console and > jm> graph devices).=20=20 > > jm> No such troubles have ever met using previous > jm> releases. How this can be explained? > > I think it might be explainable (not by me though) > once you provide more details, notably the output of > > sessionInfo() > > jm> Thanks in advance, > jm> Janek Musek > > Regards, > Martin Maechler, ETH Zurich > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ggrothendieck at gmail.com Wed Nov 5 17:10:54 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Wed, 5 Nov 2008 11:10:54 -0500 Subject: [Rd] Problem with Axis Message-ID: <971536df0811050810j2a4f2337n39e3e1312163da0b@mail.gmail.com> If we run the code below we get an error message but if we replace Axis with axis then we get no error message. I don't think Axis' error message is a good idea since one can't know ahead of time whether there is a tick at January or not since R can automatically adjust plot ranges in a complex way. For example, plot(d-13, 1:12) has a tick at Jan even though d-13 starts at jan 2nd. I think Axis should act the same as axis in this case. > d <- seq(as.Date("2008-1-15"), as.Date("2008-12-15"), by = "month") > plot(d, 1:12, xaxt = "n") > Axis(side = 1, at = d[2:12], labels = substr(month.abb[2:12], 1, 1)) > Axis(side = 1, at = as.Date("2008-1-1"), labels = "'07") Error in axis(side, at = z, labels = labels, ...) : 'at' and 'labels' lengths differ, 0 != 1 > # no error > axis(side = 1, at = as.Date("2008-1-1"), labels = "'07") > R.version.string # Vista [1] "R version 2.8.0 Patched (2008-10-21 r46766)" From anand.prabhakar.patil at gmail.com Wed Nov 5 17:29:54 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Wed, 5 Nov 2008 16:29:54 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <1225827242.4910a3aace7b9@webmail.iarc.fr> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> Message-ID: <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From plummer at iarc.fr Wed Nov 5 18:59:34 2008 From: plummer at iarc.fr (Martyn Plummer) Date: Wed, 05 Nov 2008 18:59:34 +0100 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> Message-ID: <1225907974.10672.9.camel@seurat.iarc.fr> It looks like the em64t version of MKL fails the test for the accuracy of zdotu ("checking whether double complex BLAS can be used") and is therefore dropped in favour of R's built-in BLAS. I have just tested this on Fedora and get the same result. The 32-bit MKL does work for me. Martyn On Wed, 2008-11-05 at 16:29 +0000, Anand Patil wrote: > On Tue, Nov 4, 2008 at 7:34 PM, wrote: > > > I can see a couple of problems: > > > > 1) No "-lpthread" in --with-blas > > 2) No "-L" prefix in the library path in --with-lapack > > > > In addition, I don't think you need to add -lmkl to --with-lapack, > > although that is probably harmless. > > > > Martyn > > > > Quoting Prof Brian Ripley : > > > > > Look in config.log to see what's wrong. (E.g. is > > > /opt/intel/mkl/10.0.2.018/lib/em64t in the ld.so cache?) > > > > > > And note the warnings in the manual about using --with-lapack: it is most > > > definitely not recommended. > > > > > > R-devel would be a better place to ask questions about this. > > > > > > > Thanks Brian and Martyn, > I've tried it again with two sets of configure options: > > ./configure --with-blas='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lguide > -lpthread' --with-lapack='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl_lapack' > --enable-R-shlib > > ./configure --with-blas='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lguide > -lpthread' --enable-R-shlib > > In both cases, the result is the same: R builds and uses its own BLAS. I > didn't find anything that looked like evidence that /opt/intel/mkl/ > 10.0.2.018/lib/em64t was getting into the ld.so cache, ie I didn't find > 'ld.so' and 'opt/intel...' close together anywhere. Summaries of the BLAS- > or MKL-related bits in config.log follow, with the first set of options: > > configure:36563: checking for dgemm_ in -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -lmkl -lguide -lpthread > configure:36594: gcc -std=gnu99 -o conftest -g -O2 -fpic > -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -lmkl -lguide -lpthread -lgfortran -lm -ldl -lm >&5 > conftest.c: In function 'main': > conftest.c:187: warning: implicit declaration of function 'dgemm_' > configure:36600: $? = 0 > configure:36616: result: yes > configure:37408: checking whether double complex BLAS can be used > configure:37481: result: no > ... > BLAS_LIBS0='' > BLAS_LIBS='-L$(R_HOME)/lib$(R_ARCH) -lRblas' > BLAS_SHLIB_FALSE='#' > BLAS_SHLIB_TRUE='' > ... > JAVA_LD_LIBRARY_PATH='$(JAVA_HOME)/lib/amd64/server:$(JAVA_HOME)/lib/amd64:$(JAVA_HOME)/../lib/amd64:/usr/local/lib64::/usr/lib64:/lib64:/usr/local/lib64:/usr/lib:/usr/local/lib:/lib:/opt/intel/fce/10.1.018/lib:/opt/intel/ipp/ > 5.3.4.080/em64t/sharedlib:/opt/intel/cce/10.1.018/lib:/opt/intel/mkl/10.0.2.018/lib/em64t:/usr/java/packages/lib/amd64:/lib:/usr/lib > ' > JAVA_LIBS0='-L$(JAVA_HOME)/lib/amd64/server -L$(JAVA_HOME)/lib/amd64 > -L$(JAVA_HOME)/../lib/amd64 -L/usr/local/lib64 -L -L/usr/lib64 -L/lib64 > -L/usr/local/lib64 -L/usr/lib -L/usr/local/lib -L/lib > -L/opt/intel/fce/10.1.018/lib > -L/opt/intel/ipp/5.3.4.080/em64t/sharedlib-L/opt/intel/cce/10.1.018/lib > -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -L/usr/java/packages/lib/amd64 -L/lib -L/usr/lib -ljvm' > LAPACK_LDFLAGS='' > LAPACK_LIBS='-L$(R_HOME)/lib$(R_ARCH) -lRlapack' > > > and with the second set: > > > configure:36563: checking for dgemm_ in -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -lmkl -lguide -lpthread > configure:36594: gcc -std=gnu99 -o conftest -g -O2 -fpic > -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -lmkl -lguide -lpthread -lgfortran -lm -ldl -lm >&5 > conftest.c: In function 'main': > conftest.c:187: warning: implicit declaration of function 'dgemm_' > configure:36600: $? = 0 > configure:36616: result: yes > configure:37408: checking whether double complex BLAS can be used > configure:37481: result: no > ... > BLAS_LIBS0='' > BLAS_LIBS='-L$(R_HOME)/lib$(R_ARCH) -lRblas' > BLAS_SHLIB_FALSE='#' > BLAS_SHLIB_TRUE='' > ... > JAVA_LD_LIBRARY_PATH='$(JAVA_HOME)/lib/amd64/server:$(JAVA_HOME)/lib/amd64:$(JAVA_HOME)/../lib/amd64:/usr/local/lib64::/usr/lib64:/lib64:/usr/local/lib64:/usr/lib:/usr/local/lib:/lib:/opt/intel/fce/10.1.018/lib:/opt/intel/ipp/ > 5.3.4.080/em64t/sharedlib:/opt/intel/cce/10.1.018/lib:/opt/intel/mkl/10.0.2.018/lib/em64t:/usr/java/packages/lib/amd64:/lib:/usr/lib > ' > JAVA_LIBS0='-L$(JAVA_HOME)/lib/amd64/server -L$(JAVA_HOME)/lib/amd64 > -L$(JAVA_HOME)/../lib/amd64 -L/usr/local/lib64 -L -L/usr/lib64 -L/lib64 > -L/usr/local/lib64 -L/usr/lib -L/usr/local/lib -L/lib > -L/opt/intel/fce/10.1.018/lib > -L/opt/intel/ipp/5.3.4.080/em64t/sharedlib-L/opt/intel/cce/10.1.018/lib > -L/opt/intel/mkl/ > 10.0.2.018/lib/em64t -L/usr/java/packages/lib/amd64 -L/lib -L/usr/lib -ljvm' > LAPACK_LDFLAGS='' > LAPACK_LIBS='-L$(R_HOME)/lib$(R_ARCH) -lRlapack' > > > Do either of these give us clues as to what's wrong? > > Thanks, > Anand > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ----------------------------------------------------------------------- This message and its attachments are strictly confidenti...{{dropped:8}} From anand.prabhakar.patil at gmail.com Wed Nov 5 19:01:12 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Wed, 5 Nov 2008 18:01:12 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <1225907974.10672.9.camel@seurat.iarc.fr> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> Message-ID: <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From Ray.Brownrigg at mcs.vuw.ac.nz Tue Nov 4 22:17:13 2008 From: Ray.Brownrigg at mcs.vuw.ac.nz (Ray Brownrigg) Date: Wed, 5 Nov 2008 10:17:13 +1300 Subject: [Rd] problem with integrate Message-ID: <200811051017.13175.Ray.Brownrigg@mcs.vuw.ac.nz> I am puzzled by some results I am getting from integrate(), which provides inconsistent results in some circumstances. Basically, when integrating a specific continuous function, 3 different answers are possible, varying by much more than the error bound reported by integrate(). The following script demonstrates this: # ---- start of script par(mfrow=1:2) # Define a continuous, almost everywhere differentiable, function G <- function(y) pnorm(pmin(2.241, y), lower=F, log=T)*dnorm(y) # define its integral as a sum of two integrals FUN <- function(x) integrate(G, -Inf, x)$value + integrate(G, x, Inf)$value # plot this over a small range curve(Vectorize(FUN)(x), -1.901, -1.899) # Note the error is about 0.01, but integrate() reports error < 5e-5 # Check two other ways of calculating the same integral, one wrong: abline(h = integrate(G, -Inf, Inf)$value, co l= 2) # and one "correct": abline(h = (1 - pnorm(2.241))*log(1 - pnorm(2.241)) + integrate(G, -Inf, 2.241)$value, col = 3) # Investigation reveals that the problem is with the second integral (in FUN()): FUN2 <- function(x) integrate(G, x, Inf)$value # plot this over the same range curve(Vectorize(FUN2)(x), -1.901, -1.899) # which should be the same as: abline(h = (1 - pnorm(2.241))*log(1 - pnorm(2.241)) + integrate(G, x, 2.241)$value, col = 3) # ---- end of script My actual problem is a superset of this, i.e. the constant 2.241 is only one value from a continuous range in (-4, 4). A similar problem occurs at more than a few different such values. I noticed this under version 2.7.1 (NetBSD), but have checked that it still occurs under a recently patched 2.8.0 (Windows). Ray Brownrigg Mathematics Statistics and Computer Science Victoria University of Wellington From ripley at stats.ox.ac.uk Wed Nov 5 19:39:51 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 5 Nov 2008 18:39:51 +0000 (GMT) Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> Message-ID: You can't link 32-bit libraries into 64-bit code. That test is not for accuracy but for compatible return conventions. What compilers are in use here? We've seen several instances of gcc and icc not being compatible on x86_64 (Linux and Mac OS X: not surprising as gcc3 and gcc4 are also not compatible in their return conventions), and presumably MKL is compiled with icc. Our experience with Intel compilers and MKL is uniformly negative -- less accuracy and usually slower runs. On Wed, 5 Nov 2008, Anand Patil wrote: > On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer wrote: > >> It looks like the em64t version of MKL fails the test for the accuracy >> of zdotu ("checking whether double complex BLAS can be used") and is >> therefore dropped in favour of R's built-in BLAS. I have just tested >> this on Fedora and get the same result. >> >> The 32-bit MKL does work for me. >> >> Martyn >> > > Many thanks, Martyn. The 64-bit index space is important to me, will I lose > it if I link against the 32-bit MKL? Also, should I file a bug report with > Intel? > Anand > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From P.Dalgaard at biostat.ku.dk Wed Nov 5 19:41:47 2008 From: P.Dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Wed, 05 Nov 2008 19:41:47 +0100 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> Message-ID: <4911E8EB.40305@biostat.ku.dk> Anand Patil wrote: > On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer wrote: > >> It looks like the em64t version of MKL fails the test for the accuracy >> of zdotu ("checking whether double complex BLAS can be used") and is >> therefore dropped in favour of R's built-in BLAS. I have just tested >> this on Fedora and get the same result. >> >> The 32-bit MKL does work for me. >> >> Martyn >> > > Many thanks, Martyn. The 64-bit index space is important to me, will I lose > it if I link against the 32-bit MKL? Also, should I file a bug report with > Intel? > Anand There's also the option of "breaking the thermometer". You might examine that check and decide whether the loss of accuracy is enough for you to worry about and if not, take out the test from configure. Apparently, this check was put in place in R-2.2.0 o Any external BLAS found is now tested to see if the complex routine zdotu works correctly: this provides a compatibility test of compiler return conventions. which suggests that the expected failure is catastrophic, and looking at the code, there's a fuzz of 1e-10 which would seem to be about 1e5 times larger than required. -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From plummer at iarc.fr Wed Nov 5 22:02:02 2008 From: plummer at iarc.fr (plummer at iarc.fr) Date: Wed, 05 Nov 2008 22:02:02 +0100 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <4911E8EB.40305@biostat.ku.dk> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> Message-ID: <1225918922.491209ca64fd5@webmail.iarc.fr> Quoting Peter Dalgaard : > Anand Patil wrote: > > On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer wrote: > > > >> It looks like the em64t version of MKL fails the test for the accuracy > >> of zdotu ("checking whether double complex BLAS can be used") and is > >> therefore dropped in favour of R's built-in BLAS. I have just tested > >> this on Fedora and get the same result. > >> > >> The 32-bit MKL does work for me. > >> > >> Martyn > >> > > > > Many thanks, Martyn. The 64-bit index space is important to me, will I lose > > it if I link against the 32-bit MKL? Also, should I file a bug report with > > Intel? > > Anand > > There's also the option of "breaking the thermometer". You might examine > that check and decide whether the loss of accuracy is enough for you to > worry about and if not, take out the test from configure. > > Apparently, this check was put in place in R-2.2.0 > > o Any external BLAS found is now tested to see if the complex > routine zdotu works correctly: this provides a compatibility > test of compiler return conventions. > > which suggests that the expected failure is catastrophic, and looking at > the code, there's a fuzz of 1e-10 which would seem to be about 1e5 times > larger than required. My apologies. I skimmed the code of the test program, but as Brian says it is not a question of accuracy. The test program does in fact segfault, although you won't see this in your config.log. Anyway, Anand, I would just carry on with libRblas. Martyn ----------------------------------------------------------------------- This message and its attachments are strictly confidenti...{{dropped:8}} From anand.prabhakar.patil at gmail.com Wed Nov 5 22:10:17 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Wed, 5 Nov 2008 21:10:17 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <1225918922.491209ca64fd5@webmail.iarc.fr> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> <1225918922.491209ca64fd5@webmail.iarc.fr> Message-ID: <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From peter.ruckdeschel at web.de Wed Nov 5 23:47:21 2008 From: peter.ruckdeschel at web.de (Peter Ruckdeschel) Date: Wed, 05 Nov 2008 23:47:21 +0100 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n") Message-ID: <49122279.3080203@web.de> Hi r-devels, I am a bit puzzled by the behaviour of cat() --- any help is appreciated... At least AFAICS, cat() for vector-valued '...' argument behaves in contradiction to what I understand from the note in the help to cat() which reads " Despite its name and earlier documentation, 'sep' is a vector of terminators rather than separators, being output after every vector element (including the last). Entries are recycled as needed. " ---------------------------------------------------------------------------- reproducible example code: ---------------------------------------------------------------------------- >cat(rep("x",3), sep = ".") x.x.x ## no "." appended! Things get even worse if "\n" features in the 'sep' vector: >cat(rep("x",3),sep = c(".","\n",".")) x.x x > ## last separator "." gets swallowed; an non-intended line feed is inserted ---------------------------------------------------------------------------- code causing this behaviour ---------------------------------------------------------------------------- ##### "\n" I have looked a bit into the source code (lines 468-630 in builtin.c in src/main) and found out, as variable pwidth is set to 1 in line 504, i.e.; if (strstr(CHAR(STRING_ELT(sepr, i)), "\n")) nlsep = 1; /* ASCII */ the code in lines 622-23, i.e.; if ((pwidth != INT_MAX) || nlsep) Rprintf("\n"); is responsible for the newline. Is this really intended? ##### separators, not terminators Another look shows that, contrary to what is said in the help file, an element of vector 'sep' is /not/ printed out after each element of the vector passed as argument '...' to cat(), "including the last" --- confer the for-loop over the elements of '...' in lines 596-617 and the print-out of the separator cat_printsep(sepr, ntot); in line 600. Once again: Is this intended? A patch fixing my problem would be easy, though might crash other much more important code; would you have any proposals? Best, Peter ------------------------------------------------------------------- Version: platform = i386-pc-mingw32 arch = i386 os = mingw32 system = i386, mingw32 status = Under development (unstable) major = 2 minor = 9.0 year = 2008 month = 10 day = 01 svn rev = 46589 language = R version.string = R version 2.9.0 Under development (unstable) (2008-10-01 r46589) Windows XP (build 2600) Service Pack 3 Locale: LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base From anand.prabhakar.patil at gmail.com Thu Nov 6 00:38:57 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Wed, 5 Nov 2008 23:38:57 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> <1225918922.491209ca64fd5@webmail.iarc.fr> <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> Message-ID: <2bc7a5a50811051538m4b65e1efuc5c333da454c1ae3@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From murdoch at stats.uwo.ca Thu Nov 6 00:52:31 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Wed, 05 Nov 2008 18:52:31 -0500 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n") In-Reply-To: <49122279.3080203@web.de> References: <49122279.3080203@web.de> Message-ID: <491231BF.6030007@stats.uwo.ca> On 05/11/2008 5:47 PM, Peter Ruckdeschel wrote: > Hi r-devels, > > I am a bit puzzled by the behaviour of cat() --- any help is appreciated... > > At least AFAICS, cat() for vector-valued '...' argument behaves in > contradiction to what I understand from the note in the help to cat() > which reads > > " > Despite its name and earlier documentation, 'sep' is a vector of > terminators rather than separators, being output after every > vector element (including the last). Entries are recycled as > needed. > " I think you're right that the documentation is incorrect. I'd prefer a patch to the docs, rather than a change to the behaviour: cat() is so fundamental that any changes to it would have wide ranging consequences. If you want to study the code and draft a documentation patch, I'll review it and possibly commit it. Duncan Murdoch > ---------------------------------------------------------------------------- > reproducible example code: > ---------------------------------------------------------------------------- > >> cat(rep("x",3), sep = ".") > x.x.x > ## no "." appended! > > Things get even worse if "\n" features in the 'sep' vector: > >> cat(rep("x",3),sep = c(".","\n",".")) > x.x > x > ## last separator "." gets swallowed; an non-intended line feed is > inserted > > ---------------------------------------------------------------------------- > code causing this behaviour > ---------------------------------------------------------------------------- > ##### "\n" > > I have looked a bit into the source code > (lines 468-630 in builtin.c in src/main) > and found out, as variable pwidth is set to 1 in line 504, i.e.; > > if (strstr(CHAR(STRING_ELT(sepr, i)), "\n")) nlsep = 1; /* ASCII */ > > the code in lines 622-23, i.e.; > > if ((pwidth != INT_MAX) || nlsep) > Rprintf("\n"); > > is responsible for the newline. Is this really intended? > > ##### separators, not terminators > > Another look shows that, contrary to what is said in the help file, > an element of vector 'sep' is /not/ printed out after each element > of the vector passed as argument '...' to cat(), "including the last" > --- confer the for-loop over the elements of '...' in lines 596-617 > and the print-out of the separator > > cat_printsep(sepr, ntot); > > in line 600. Once again: Is this intended? > > A patch fixing my problem would be easy, though might crash > other much more important code; would you have any > proposals? > > Best, > Peter > > ------------------------------------------------------------------- > Version: > platform = i386-pc-mingw32 > arch = i386 > os = mingw32 > system = i386, mingw32 > status = Under development (unstable) > major = 2 > minor = 9.0 > year = 2008 > month = 10 > day = 01 > svn rev = 46589 > language = R > version.string = R version 2.9.0 Under development (unstable) > (2008-10-01 r46589) > > Windows XP (build 2600) Service Pack 3 > > Locale: > LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 > > Search Path: > .GlobalEnv, package:stats, package:graphics, package:grDevices, > package:utils, package:datasets, package:methods, Autoloads, package:base > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From smckinney at bccrc.ca Thu Nov 6 01:45:58 2008 From: smckinney at bccrc.ca (Steven McKinney) Date: Wed, 5 Nov 2008 16:45:58 -0800 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n") References: <49122279.3080203@web.de> <24197_1225929173_1225929173_491231BF.6030007@stats.uwo.ca> Message-ID: <0BE438149FF2254DB4199E2682C8DFEB0328A4C8@crcmail1.BCCRC.CA> > On 05/11/2008 5:47 PM, Peter Ruckdeschel wrote: > > Hi r-devels, > > > > I am a bit puzzled by the behaviour of cat() --- any help is > > appreciated... It appears to me that the elements of sep are just used as separators _between_ each of the objects comprising '...' handed to cat. If N objects are handed to cat, cat requires N-1 separator strings. The default separator string is " " (space character). Hence for cat(rep("x",3), sep = ".") two periods are needed to separate the three input objects > cat(rep("x",3), sep = ".") x.x.x > as expected. For cat(rep("x",3),sep = c(".","\n",".")), the first separator is a period, the second is a newline, and the third is not needed. > cat(rep("x",3),sep = c(".","\n",".")) x.x x > as expected. The line feed inserted is expected, it is the second element of the sep vector, so should appear between the second and third objects, as it does. The third element of sep is not needed, so is ignored. Another example: > cat(letters, sep = c(as.character(1:9), "\n")) a1b2c3d4e5f6g7h8i9j k1l2m3n4o5p6q7r8s9t u1v2w3x4y5z > Again, as expected. Slightly more complex > paste("[", c(as.character(1:9), "\n"), "]", sep = "") [1] "[1]" "[2]" "[3]" "[4]" "[5]" "[6]" "[7]" "[8]" "[9]" "[\n]" > cat(letters, sep = paste("[", c(as.character(1:9), "\n"), "]", sep = "")) a[1]b[2]c[3]d[4]e[5]f[6]g[7]h[8]i[9]j[ ]k[1]l[2]m[3]n[4]o[5]p[6]q[7]r[8]s[9]t[ ]u[1]v[2]w[3]x[4]y[5]z > again, as expected. I haven't delved into the source to see where the final line feed is being generated (as I see the next R prompt on a new line) so I can't comment on whether anything is appended to the end of the output string generated by cat(). The documentation says no line feed is appended unless argument 'fill' is TRUE or numeric. > > > > At least AFAICS, cat() for vector-valued '...' argument behaves in > > contradiction to what I understand from the note in the help to cat() > > which reads > > > > " > > Despite its name and earlier documentation, 'sep' is a vector of > > terminators rather than separators, being output after every > > vector element (including the last). Entries are recycled as > > needed. > > " > > I think you're right that the documentation is incorrect. I'd prefer a > patch to the docs, rather than a change to the behaviour: cat() is so > fundamental that any changes to it would have wide ranging consequences. > > If you want to study the code and draft a documentation patch, I'll > review it and possibly commit it. How about this: sep a character vector of strings to insert between each object. If there are too few elements in sep to separate all the objects, the elements of sep are recycled. Unused elements of sep are ignored. then in Details: Details cat is useful for producing output in user-defined functions. It converts its arguments to character vectors, concatenates them to a single character vector, inserts the given sep= string(s) between each element and then outputs them. > > Duncan Murdoch > > > ---------------------------------------------------------------------------- > > reproducible example code: > > ---------------------------------------------------------------------------- > > > >> cat(rep("x",3), sep = ".") > > x.x.x > > ## no "." appended! > > > > Things get even worse if "\n" features in the 'sep' vector: > > > >> cat(rep("x",3),sep = c(".","\n",".")) > > x.x > > x > > ## last separator "." gets swallowed; an non-intended line feed is > > inserted > > > > ---------------------------------------------------------------------------- > > code causing this behaviour > > ---------------------------------------------------------------------------- > > ##### "\n" > > > > I have looked a bit into the source code > > (lines 468-630 in builtin.c in src/main) > > and found out, as variable pwidth is set to 1 in line 504, i.e.; > > > > if (strstr(CHAR(STRING_ELT(sepr, i)), "\n")) nlsep = 1; /* ASCII */ > > > > the code in lines 622-23, i.e.; > > > > if ((pwidth != INT_MAX) || nlsep) > > Rprintf("\n"); > > > > is responsible for the newline. Is this really intended? > > > > ##### separators, not terminators > > > > Another look shows that, contrary to what is said in the help file, > > an element of vector 'sep' is /not/ printed out after each element > > of the vector passed as argument '...' to cat(), "including the last" > > --- confer the for-loop over the elements of '...' in lines 596-617 > > and the print-out of the separator > > > > cat_printsep(sepr, ntot); > > > > in line 600. Once again: Is this intended? > > > > A patch fixing my problem would be easy, though might crash > > other much more important code; would you have any > > proposals? > > > > Best, > > Peter > > > > ------------------------------------------------------------------- > > Version: > > platform = i386-pc-mingw32 > > arch = i386 > > os = mingw32 > > system = i386, mingw32 > > status = Under development (unstable) > > major = 2 > > minor = 9.0 > > year = 2008 > > month = 10 > > day = 01 > > svn rev = 46589 > > language = R > > version.string = R version 2.9.0 Under development (unstable) > > (2008-10-01 r46589) > > > > Windows XP (build 2600) Service Pack 3 > > > > Locale: > > LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252 > > > > Search Path: > > .GlobalEnv, package:stats, package:graphics, package:grDevices, > > package:utils, package:datasets, package:methods, Autoloads, package:base > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: smckinney +at+ bccrc +dot+ ca tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada From wdunlap at tibco.com Thu Nov 6 01:51:04 2008 From: wdunlap at tibco.com (William Dunlap) Date: Wed, 5 Nov 2008 16:51:04 -0800 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n") In-Reply-To: <491231BF.6030007@stats.uwo.ca> References: <49122279.3080203@web.de> <491231BF.6030007@stats.uwo.ca> Message-ID: <77EB52C6DD32BA4D87471DCD70C8D7001DE739@NA-PA-VBE03.na.tibco.com> > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Duncan Murdoch > Sent: Wednesday, November 05, 2008 3:53 PM > To: Peter Ruckdeschel > Cc: r-devel at r-project.org > Subject: Re: [Rd] puzzled by cat() behaviour when argument > '...' is a vector (and argument 'sep' contains "\n") > > On 05/11/2008 5:47 PM, Peter Ruckdeschel wrote: > > Hi r-devels, > > > > I am a bit puzzled by the behaviour of cat() --- any help > is appreciated... > > > > At least AFAICS, cat() for vector-valued '...' argument behaves in > > contradiction to what I understand from the note in the > help to cat() > > which reads > > > > " > > Despite its name and earlier documentation, 'sep' is a vector of > > terminators rather than separators, being output after every > > vector element (including the last). Entries are recycled as > > needed. > > " > > I think you're right that the documentation is incorrect. > I'd prefer a patch to the docs, rather than a change to the > behaviour: cat() is so fundamental that any changes to it > would have wide ranging consequences. > > If you want to study the code and draft a documentation > patch, I'll review it and possibly commit it. > > Duncan Murdoch For what it is worth, S+ and R differ in how a vector sep argument is treated. R uses the vector sep only if cat() is given a vector of strings for the ... argument but S+ treats cat(c(...),sep=sep) the same as cat(..., sep=sep). E.g., the following cat(...,sep=sep) uses all of sep in S+ but only sep[1] in R: > cat("One.", "Two words.", "Three more words.", sep=c("", "\n", "")) S+: One.Two words. S+: Three more words. R : One.Two words.Three more words. but the following cat(c(...),sep=sep) uses all of sep in both > cat(c("One.", "Two words.", "Three more words."), sep=c("", "\n", "")) S+: One.Two words. S+: Three more words. R : One.Two words. R : Three more words. If there are several c(...) entries in cat() it gets more complicated. E.g., > cat(c("One.", "Two words.", "Three more words."), c("Fourth entry.", "No. 5."), sep=c("", "\n", "")) S+: One.Two words. S+: Three more words.Fourth entry.No. 5. R : One.Two words. R : Three more words.Fourth entry.No. 5. In both, if any of the sep values include a newline, a newline is appended to the end of the cat() output. Neither use any entry in sep after the end of the cat() output, although, because of the previous rule, it may seem that they do in the common case of sep="". I had forgotten that sep= could be vectorized and use paste() instead of cat() when I needed such functionality. IMO, paste() has fewer surprises. Bill Dunlap TIBCO Spotfire Inc wdunlap tibco.com From wdunlap at tibco.com Thu Nov 6 02:05:26 2008 From: wdunlap at tibco.com (William Dunlap) Date: Wed, 5 Nov 2008 17:05:26 -0800 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector(and argument 'sep' contains "\n") In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D7001DE739@NA-PA-VBE03.na.tibco.com> References: <49122279.3080203@web.de> <491231BF.6030007@stats.uwo.ca> <77EB52C6DD32BA4D87471DCD70C8D7001DE739@NA-PA-VBE03.na.tibco.com> Message-ID: <77EB52C6DD32BA4D87471DCD70C8D7001DE74D@NA-PA-VBE03.na.tibco.com> > -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of William Dunlap > Sent: Wednesday, November 05, 2008 4:51 PM > To: Duncan Murdoch; Peter Ruckdeschel > Cc: r-devel at r-project.org > Subject: Re: [Rd] puzzled by cat() behaviour when argument > '...' is a vector(and argument 'sep' contains "\n") ... > Neither use any entry in sep after the end of the cat() > output, although, because of the previous rule, it may seem > that they do in the common case of sep="". I meant 'common case of sep="\n"'. > I had forgotten that sep= could be vectorized and use paste() > instead of > cat() when I needed such functionality. IMO, paste() has > fewer surprises. > > Bill Dunlap > TIBCO Spotfire Inc > wdunlap tibco.com From ripley at stats.ox.ac.uk Thu Nov 6 07:48:53 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Thu, 6 Nov 2008 06:48:53 +0000 (GMT) Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811051538m4b65e1efuc5c333da454c1ae3@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> <1225918922.491209ca64fd5@webmail.iarc.fr> <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> <2bc7a5a50811051538m4b65e1efuc5c333da454c1ae3@mail.gmail.com> Message-ID: And how does that help you? At some future point on a real problem you will get incorrect answers/segfault. That test was put there as a result of such incorrect results found the hard way. On Wed, 5 Nov 2008, Anand Patil wrote: > Scratch that- finally got it working! The steps were: > - Change configure to 'break the thermometer' as suggested: > =================================================================== > --- configure ? (revision 46843) > +++ configure ? (working copy) > @@ -37473,6 +37473,8 @@ > ? > ?fi > ? > +r_cv_zdotu_is_usable=yes > + > ?? rm -rf conftest conftest.* conftestf.* core > ?? if test -n "${r_cv_zdotu_is_usable}"; then > ?? ? { echo "$as_me:$LINENO: result: yes" >&5 > > - Set environment variables: > CFLAGS=-pthread -O3 > FC=gfortran -pthread > FFLAGS=-pthread > CXXFLAGS=-O3 -pthread > FCLAGS=-pthread > LDFLAGS=-lpthread > > - Configure command: > ./configure --with-blas='-L/opt/intel/mkl/10.0.2.018/lib/em64t -lmkl -lguide > -lpthread' --enable-R-shlib > > I owe you all a beer! > > Anand > > > On Wed, Nov 5, 2008 at 9:10 PM, Anand Patil > wrote: > Thanks for your help, everyone. I was using gcc previously, but > building with the Intel compilers causes its own problems: > /opt/intel/cce/10.1.018/lib/libguide.so: undefined reference to > `pthread_atfork' > make[3]: *** [R.bin] Error 1 > make[3]: Leaving directory `/working_copies/R/src/main' > make[2]: *** [R] Error 2 > make[2]: Leaving directory `/working_copies/R/src/main' > make[1]: *** [R] Error 1 > make[1]: Leaving directory `/working_copies/R/src' > make: *** [R] Error 1 > > If your experience with MKL has been negative, I've definitely had > enough; I'll try my luck with gcc and GotoBLAS.? > > Cheers, > Anand > > > On Wed, Nov 5, 2008 at 9:02 PM, wrote: > Quoting Peter Dalgaard : > > > Anand Patil wrote: > > > On Wed, Nov 5, 2008 at 5:59 PM, Martyn Plummer > wrote: > > > > > >> It looks like the em64t version of MKL fails the test > for the accuracy > > >> of zdotu ("checking whether double complex BLAS can > be used") and is > > >> therefore dropped in favour of R's built-in BLAS. ?I > have just tested > > >> this on Fedora and get the same result. > > >> > > >> The 32-bit MKL does work for me. > > >> > > >> Martyn > > >> > > > > > > Many thanks, Martyn. The 64-bit index space is > important to me, will I lose > > > it if I link against the 32-bit MKL? Also, should I > file a bug report with > > > Intel? > > > Anand > > > > There's also the option of "breaking the thermometer". > You might examine > > that check and decide whether the loss of accuracy is > enough for you to > > worry about and if not, take out the test from > configure. > > > > Apparently, this check was put in place in R-2.2.0 > > > > ? ? o Any external BLAS found is now tested to see if > the complex > > ? ? ? ? routine zdotu works correctly: this provides a > compatibility > > ? ? ? ? test of compiler return conventions. > > > > which suggests that the expected failure is > catastrophic, and looking at > > the code, there's a fuzz of 1e-10 which would seem to be > about 1e5 times > > larger than required. > > My apologies. I skimmed the code of the test program, but as > Brian says > it is not a question of accuracy. The test program does in fact > segfault, > although you won't see this in your config.log. > > Anyway, Anand, I would just carry on with libRblas. > > Martyn > > > > ----------------------------------------------------------------------- > This message and its attachments are strictly confiden...{{dropped:26}} From anand.prabhakar.patil at gmail.com Thu Nov 6 10:24:59 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Thu, 6 Nov 2008 09:24:59 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> <1225918922.491209ca64fd5@webmail.iarc.fr> <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> <2bc7a5a50811051538m4b65e1efuc5c333da454c1ae3@mail.gmail.com> Message-ID: <2bc7a5a50811060124w25a9b870k8b51222d9f41335a@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Thu Nov 6 10:44:41 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Thu, 06 Nov 2008 10:44:41 +0100 Subject: [Rd] puzzled by cat() behaviour when argument '...' is a vector (and argument 'sep' contains "\n") In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D7001DE739@NA-PA-VBE03.na.tibco.com> References: <49122279.3080203@web.de> <491231BF.6030007@stats.uwo.ca> <77EB52C6DD32BA4D87471DCD70C8D7001DE739@NA-PA-VBE03.na.tibco.com> Message-ID: <4912BC89.1020809@idi.ntnu.no> William Dunlap wrote: > > For what it is worth, S+ and R differ in how a vector sep argument > is treated. R uses the vector sep only if cat() is given a vector of > strings for the ... argument but S+ treats cat(c(...),sep=sep) > the same as cat(..., sep=sep). E.g., the following cat(...,sep=sep) > uses all of sep in S+ but only sep[1] in R: > > cat("One.", "Two words.", "Three more words.", > sep=c("", "\n", "")) > S+: One.Two words. > S+: Three more words. > R : One.Two words.Three more words. > but the following cat(c(...),sep=sep) uses all of sep in both > > cat(c("One.", "Two words.", "Three more words."), > sep=c("", "\n", "")) > S+: One.Two words. > S+: Three more words. > R : One.Two words. > R : Three more words. > If there are several c(...) entries in cat() it gets more complicated. > E.g., > > cat(c("One.", "Two words.", "Three more words."), c("Fourth > entry.", "No. 5."), > sep=c("", "\n", "")) > S+: One.Two words. > S+: Three more words.Fourth entry.No. 5. > R : One.Two words. > R : Three more words.Fourth > entry.No. 5. > > cat ues consecutive elements of sep circularly (see below) to separate elements *within* each item in ..., and uses the first element in sep as a separator *between* items in ... cat(1:5, sep=letters[1:3]) # evaluates to "1a2b3c4a5" cat(1:5, 6, sep=letters[1:3]) # evaluates to "1a2b3c4a5a6" cat(1:5, 6, 7, sep=letters[1:3]) # evaluates to "1a2b3c4a5a6a7" confusingly, the circulation over sep is *not* restarted for each item in ..., and it is *not* stopped while separating between items in ... cat(1:5, 6:10, sep=letters[1:3]) # evaluates to "1a2b3c4a5a6c7a8b9c10", # not to "1a2b3c4a5a6a7b8c9a10" (which would be the case if circulation were restarted for each item), and # not to "1a2b3c4a5a6b7c8a9b10" (which would be the case if circulation were not restarted, but were stopped for between-item separation) cat(1:5, 6, 7:10, sep=letters[1:3]) # evaluates to "1ab3c4a5a6a7a8b9c10" (which is only *incidentally* the same as it would be if circulation were restarted for each item), and # not to "1a2b3c4a5a6a7b8c9a10" (which would be the case if circulation were not restarted, but were stopped for between-item separation) whether this is or is not reasonable, the man page should be explicit about this behaviour, and the example section should clearly illustrate it. the examples above are a candidate. i am not sure that there is any good scenario of where this behaviour would be desirable and useful, and perhaps redesigning cat should be an option to consider. vQ ps. still using R 2.7.0, but i guess cat has not changed since. From ripley at stats.ox.ac.uk Thu Nov 6 10:45:14 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Thu, 6 Nov 2008 09:45:14 +0000 (GMT) Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811060124w25a9b870k8b51222d9f41335a@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <1225827242.4910a3aace7b9@webmail.iarc.fr> <2bc7a5a50811050829o2904bddbw8be864d087096640@mail.gmail.com> <1225907974.10672.9.camel@seurat.iarc.fr> <2bc7a5a50811051001j25ec2359x66009cd74852d9eb@mail.gmail.com> <4911E8EB.40305@biostat.ku.dk> <1225918922.491209ca64fd5@webmail.iarc.fr> <2bc7a5a50811051310y2ccaee02p39a093add499bc9b@mail.gmail.com> <2bc7a5a50811051538m4b65e1efuc5c333da454c1ae3@mail.gmail.com> <2bc7a5a50811060124w25a9b870k8b51222d9f41335a@mail.gmail.com> Message-ID: On Thu, 6 Nov 2008, Anand Patil wrote: > On Thu, Nov 6, 2008 at 6:48 AM, Prof Brian Ripley wrote: > And how does that help you? ?At some future point on a real problem you will get > incorrect answers/segfault. > > That test was put there as a result of such incorrect results found the hard way. > > > I appreciate that... but I never use the complex blas, so in my case the test is preventing me > from taking advantage of MKL's real blas. Or is the zdotu error symptomatic of a problem that > would affect the real blas also? Only complex BLASAFAIK, *but* e.g. lapack uses it internally, AFAIK even for real inputs. > > Anand > > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From anand.prabhakar.patil at gmail.com Thu Nov 6 11:00:00 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Thu, 6 Nov 2008 10:00:00 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> Message-ID: <2bc7a5a50811060200h13f8140bpd026840216a12646@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From nakama at ki.rim.or.jp Thu Nov 6 16:08:55 2008 From: nakama at ki.rim.or.jp (Ei-ji Nakama) Date: Fri, 7 Nov 2008 00:08:55 +0900 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: <2bc7a5a50811060200h13f8140bpd026840216a12646@mail.gmail.com> References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <2bc7a5a50811060200h13f8140bpd026840216a12646@mail.gmail.com> Message-ID: Hi 2008/11/6 Anand Patil : > I tried that earlier, and it doesn't encounter the zdotu error (maybe it was > fixed in 10.0.5?) but I got a different error: no, see MKL manual. Because fortran do not have compatibility, You appoint ABI of your Fortran in a link of MKL. > /opt/intel/fce/10.1.018/lib/libiomp5.so: undefined reference to > `pthread_atfork' MKL 10.0.1.x that libiomp5 was necessary. Hmm, but not need libiomp5 with MKL 10.0.5.x. I do not understand which version MKL were recovered in, but libiomp5 seems to be unnecessary in the latest edition. MKL_LIB_PATH=/opt/intel/mkl/10.0.5.025/lib/em64t MKL=" -L${MKL_LIB_PATH} \ -Wl,--start-group \ ${MKL_LIB_PATH}/libmkl_gf_lp64.a \ ${MKL_LIB_PATH}/libmkl_gnu_thread.a \ ${MKL_LIB_PATH}/libmkl_core.a \ -Wl,--end-group -lgomp" LDFLAGS="-L$MKL_LIB_PATH" ./configure --with-lapack="$MKL" --with-blas="$MKL" -liomp5 -lguide -lpthread You omit three library, and please link Please check the result of the big %*% just to make sure. -- EI-JI Nakama "\u4e2d\u9593\u6804\u6cbb" From anand.prabhakar.patil at gmail.com Thu Nov 6 16:35:16 2008 From: anand.prabhakar.patil at gmail.com (Anand Patil) Date: Thu, 6 Nov 2008 15:35:16 +0000 Subject: [Rd] [R] Building with MKL on Ubuntu In-Reply-To: References: <2bc7a5a50811041000u698ccbdm252e2209735192f1@mail.gmail.com> <2bc7a5a50811060200h13f8140bpd026840216a12646@mail.gmail.com> Message-ID: <2bc7a5a50811060735j6bfdf226ufaed7f3dbfb129cc@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From charlie.xia.fdu at gmail.com Thu Nov 6 19:16:25 2008 From: charlie.xia.fdu at gmail.com (charlie) Date: Thu, 6 Nov 2008 10:16:25 -0800 Subject: [Rd] Fwd: SWIG with R and C++ STL In-Reply-To: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> Message-ID: <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From peter.ruckdeschel at web.de Thu Nov 6 19:26:41 2008 From: peter.ruckdeschel at web.de (Peter Ruckdeschel) Date: Thu, 06 Nov 2008 19:26:41 +0100 Subject: [Rd] Two minor escaping issues using \preformatted{....} in Rd format Message-ID: <491336E1.6010702@web.de> Hi r-devels, I have two minor problems with special characters in Rd files when used within a \preformatted{} markup command: ------------------------------------------------------ 1. issue: backslash + single brace ------------------------------------------------------ I would like to write "\\\}" to produce \} on output (documenting the need to escape the brace once again before TeX-ing it); this fails if there is no space between the second and third backslash, but works if there is a space, but this produces \ } then.... ------------------------------------------------------ 2. issue: backslash + percent sign ------------------------------------------------------ I would like to write "\\\\\%" to give a string argument \\% on output; this is needed for documenting how to register special operators to TeX package 'listings'. Again this fails, while "\\\\ \%" works. In neither case 1 or 2 the standard TeX trick to produce a linebreak in the source without producing a space on output helps, i.e. \\% \} resp. \\\\% \% both produce valid code [the resp. first % is read as a comment sign] but also insert a non-intended space in the output. Any idea how to circumvent this? Best, Peter From armstrong.whit at gmail.com Thu Nov 6 20:29:25 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Thu, 6 Nov 2008 14:29:25 -0500 Subject: [Rd] Fwd: SWIG with R and C++ STL In-Reply-To: <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> Message-ID: <8ec76080811061129p2e54125eqee948a31bb4a4de8@mail.gmail.com> did you wrap your function prototype in extern "C" ? -Whit On Thu, Nov 6, 2008 at 1:16 PM, charlie wrote: > Hi, all > > I didn't get any response from swig for my question. > see if I can get some help here > > Thanks > > ---------- Forwarded message ---------- > From: charlie > Date: Tue, Nov 4, 2008 at 1:55 PM > Subject: SWIG with R and C++ STL > To: swig-user at lists.sourceforge.net > > > Hi all, > > I am new to SWIG. I encountered some problem when I try to SWIG to R some > C++ modules. > Here is the details. I got "myvector.i" and "myvector.h" as my two input > files, the contends are: > > ---myvector.i----- > %module myvector > %{ > #include "myvector.h" > %} > > %include "std_vector.i" > > namespace std { > %template(IntVector) vector; > %template(DoubleVector) vector; > }; > > %include "myvector.h" > ---------------------------------- > > --myvector.h------------------- > /* File : example.h */ > > #include > #include > #include > #include > > double average(std::vector v) { > return std::accumulate(v.begin(),v.end(),0.0)/v.size(); > } > > std::vector half(const std::vector& v) { > std::vector w(v); > for (unsigned int i=0; i w[i] /= 2.0; > return w; > } > > void halve_in_place(std::vector& v) { > std::transform(v.begin(),v.end(),v.begin(), > std::bind2nd(std::divides(),2.0)); > } > ------------------------------------- > > Basicly they are just examples from the SWIG doc. > And I ran: > *swig -c++ -r -o myvector_wrap.cpp myvector.i > PKG_LIBS="myvector.h" R CMD SHLIB myvector_wrap.cpp* > Then in R I ran: >>*dyn.load("myvector.so")* >>*source("myvector.R")* > Then i tried to create a vector in R: >>*vi=IntVector(4)* > I go the following error: > *Error in .Call("R_swig_new_IntVector__SWIG_2", size, PACKAGE="myvector"): > C symbol name "R_swig_new_IntVector__SWIG_2" not in DLL for package > "myvector"* > > Since I basicly followed the steps in the doc, I don't understand where the > error comes from. > Can anybody help me out? > > Thanks a lot! > > Charlie > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From m_kempenaar at planet.nl Thu Nov 6 21:05:49 2008 From: m_kempenaar at planet.nl (MarcelK) Date: Thu, 6 Nov 2008 12:05:49 -0800 (PST) Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? Message-ID: <20368695.post@talk.nabble.com> Hello, I'm trying to create my own C code for use within R. While optimizing the code I've noticed that even while only using pointers to get my data to C the time needed still depends on data (vector) size. To test this, I've created an empty C function to which I've send vectors containing various sizes of elements. The time needed for each call is measured and plotted. I would expect a flat line (a little above y=0) since the only thing send are pointers. What I do not expect is to see a linear climbing line when the vector size increases. Initializing the vectors isn't being measured, only the '.C' call to an empty C function, see below. Is there anything I'm missing that can explain this input-size dependent latency? The only reason I can think of is that these vectors are being copied along the way. What follows is both the R and C code which I use only for testing and a plot of both measurements with DUP=TRUE and DUP=FALSE: (RED: DUP=FALSE, GREEN: DUP=TRUE) http://www.nabble.com/file/p20368695/CandR.png R code: ---------- # sequence from 512 to 2^23 with 2^17 stepsize a <- seq(512, 2^23, 2^17) # storage for wall time h <- length(a); j <- length(a) for (i in 1:length(a)) { x <- as.double(1:a[i]) y <- as.double(x) # system.time()[3] is (actual) wall time h[i] <- system.time(.C("commTest", x, y, DUP=FALSE))[3] j[i] <- system.time(.C("commTest", x, y, DUP=TRUE))[3] x <- 0 y <- 0 } # plot: plot(a, h, type="l", col="red", xlab="Vector Size -->", ylab="Time in Seconds -->"); lines(a, j, col="green") C code: ----------- #include extern "C" { void commTest(double* a, double* b); } /* * Empty function * Just testing communication costs between R --> C */ void commTest(double* a, double* b) { /* Do ab-so-lute-ly-nothing.. */ } System Details: --------------------- Linux gpu 2.6.18-6-amd64 #1 SMP Thu May 8 06:49:39 UTC 2008 x86_64 GNU/Linux R version 2.7.1 (2008-06-23) -- View this message in context: http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20368695.html Sent from the R devel mailing list archive at Nabble.com. From m_kempenaar at planet.nl Thu Nov 6 21:09:18 2008 From: m_kempenaar at planet.nl (MarcelK) Date: Thu, 6 Nov 2008 12:09:18 -0800 (PST) Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? In-Reply-To: <20368695.post@talk.nabble.com> References: <20368695.post@talk.nabble.com> Message-ID: <20368753.post@talk.nabble.com> Sorry for spamming, legend with the plot is wrong: RED: DUP = TRUE GREEN: DUP = FALSE Pretty clear from the plot itself, but it's both wrong in the plot header and in the plot code (just swap 'h' and 'j'). -- View this message in context: http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20368753.html Sent from the R devel mailing list archive at Nabble.com. From wdunlap at tibco.com Thu Nov 6 21:12:01 2008 From: wdunlap at tibco.com (William Dunlap) Date: Thu, 6 Nov 2008 12:12:01 -0800 Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? In-Reply-To: <20368695.post@talk.nabble.com> References: <20368695.post@talk.nabble.com> Message-ID: <77EB52C6DD32BA4D87471DCD70C8D7001DE979@NA-PA-VBE03.na.tibco.com> > -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of MarcelK > Sent: Thursday, November 06, 2008 12:06 PM > To: r-devel at r-project.org > Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? > > > Hello, > > I'm trying to create my own C code for use within R. While > optimizing the code I've noticed that even while only using > pointers to get my data to C the time needed still depends on > data (vector) size. Does using NAOK=TRUE in the .C() help? That would avoid an NA-scan of the input vectors. Bill Dunlap TIBCO Spotfire Inc wdunlap tibco.com From ggrothendieck at gmail.com Thu Nov 6 21:25:12 2008 From: ggrothendieck at gmail.com (ggrothendieck at gmail.com) Date: Thu, 6 Nov 2008 21:25:12 +0100 (CET) Subject: [Rd] Axis gives error message (PR#13259) Message-ID: <20081106202512.81934282EFF0@mail.pubhealth.ku.dk> Full_Name: G. Grothendieck Version: R version 2.8.0 Patched (2008-10-21 r46766) OS: Vista Submission from: (NULL) (69.63.56.110) Was posted here on r-devel https://stat.ethz.ch/pipermail/r-devel/2008-November/051173.html but got no replies. From adrian_d at eskimo.com Thu Nov 6 16:04:08 2008 From: adrian_d at eskimo.com (Adrian Dragulescu) Date: Thu, 6 Nov 2008 07:04:08 -0800 (PST) Subject: [Rd] problem packaging S4 class that contains a slot of jobjRef class Message-ID: Hello, I'm trying to package some source files that link R to a broker using a Java API and the rJava package. I am successful doing the connection and operate on it using my R code. I would like to package the files and release the package. I created some S4 classes to hold several Java objects. I use WinXP and R 2.7.1. I've searched RSeek and the Wiki for help, but could not find a solution. Here is my class definition: twsConnect <- function(...) new("twsConnect", ...) setClass( Class="twsConnect", representation=representation( clientId = "integer", host = "character", port = "integer", reference = "jobjRef"), prototype=prototype( clientId = as.integer(0), host = "", port = as.integer(7496), reference = .jnull()) ) setMethod("initialize", "twsConnect", function( .Object, clientId = 0, host = "", port = 7496, ...) { # hook up to the TWS ref <- .jnew("dev/AAD_Trader", as.integer(clientId), host, as.integer(port)) if (class(ref)[1] != "jobjRef") stop("Could not connect. Check your settings.") .Object at clientId <- as.integer(clientId) .Object at host <- as.character(host) .Object at port <- as.integer(port) .Object at reference <- ref .Object } ) setMethod("show", "twsConnect", function(object){ cat("Object of class \"", class(object), "\":\n", sep="") lines <- NULL for (s in slotNames(object)){ cont <- slot(object, s) if (is.character(cont))cont <- paste('"', cont, '"', sep="") if (class(cont)=="jobjRef") cont <- "jobjRef" lines <- paste(lines, paste(s, " = ", cont, "\n", sep=""), sep="") } cat(lines) } ) I have other files too. Here is the output from package creation: S:\All\Risk\Software\R\R-2.7.1\bin>Rcmd build --force --binary H:/user/R/Adrian/RIB/ * checking for file 'H:/user/R/Adrian/RIB/DESCRIPTION' ... OK * preparing 'H:/user/R/Adrian/RIB': * checking DESCRIPTION meta-information ... OK * removing junk files * excluding invalid files from 'RIB' Subdirectory 'R' contains invalid file names: .make.IB.package.R .utilities.R * checking for LF line-endings in source and make files * checking for empty or unneeded directories WARNING: directory 'RIB/inst/doc' is empty * building binary distribution WARNING: some HTML links may not be found installing R.css in C:/DOCUME~1/e47187/LOCALS~1/Temp/Rinst238480883 Using auto-selected zip options '' ---------- Making package RIB ------------ adding build stamp to DESCRIPTION installing NAMESPACE file and metadata installing R files installing inst files preparing package RIB for lazy loading Loading required package: rJava Warning: package 'rJava' was built under R version 2.7.2 Loading required package: zoo Attaching package: 'zoo' The following object(s) are masked from package:base : as.Date.numeric Creating a new generic function for "summary" in "RIB" installing man source files installing indices installing help >>> Building/Updating help pages for package 'RIB' Formats: text html latex example chm IBrokers-package text html latex example chm reqAccountUpdates text html latex example chm reqHistoricalData text html latex example chm twsConnect text html latex example chm Note: removing empty section \details Note: removing empty section \details twsContract text html latex example chm twsOrder text html latex example chm hhc: not found CHM compile failed: HTML Help Workshop not installed? adding MD5 sums packaged installation of package 'RIB' as RIB_0.1.0.zip * DONE (RIB) Not clean yet, but good for testing. So, from R: > require("RIB") Loading required package: RIB Loading required package: rJava Loading required package: zoo Attaching package: 'zoo' The following object(s) are masked from package:base : as.Date.numeric Warning message: package 'rJava' was built under R version 2.7.2 > tws <- twsConnect() > tws Object of class "twsConnect": clientId = 0 host = "" port = 7496 reference = jobjRef > tws at reference [1] "Java-Object" So I have no connection... > tws <- new("twsConnect", 1, "", 7496) Error in initialize(value, ...) : cannot use object of class "numeric" in new(): class "twsConnect" does not extend that class > but if I source the file: > source("H:/user/R/Adrian/RIB/R/twsConnect.R") > tws <- twsConnect() > tws Object of class "twsConnect": clientId = 0 host = "" port = 7496 reference = jobjRef > > tws at reference [1] "Java-Object{dev.AAD_Trader at 12558d6}" > Things work as I want, I have the connection. What does source do, that I miss when packaging? My NAMESPACE file is: exportPattern("^[^\\.]") exportClasses("twsConnect", "twsContract", "twsExecutionFilter", "twsOrder") exportMethods("show") My .onLoad function contains ".jpackage(pkgname)". I tried to package just the class twsConnect without the slot reference, and things worked out fine. I tried to say that twsConnect contains "jobjRef" but did not have much success. Thanks a lot, Adrian Dragulescu From jon at epcc.ed.ac.uk Thu Nov 6 17:25:03 2008 From: jon at epcc.ed.ac.uk (jon at epcc.ed.ac.uk) Date: Thu, 6 Nov 2008 17:25:03 +0100 (CET) Subject: [Rd] Compile error when configured with (PR#13256) Message-ID: <20081106162503.B53B1282EFF6@mail.pubhealth.ku.dk> Full_Name: Jon Hill Version: 2.8.1 OS: Linux Submission from: (NULL) (129.215.63.157) A semicolon is missing from src/main/platform.c line 1657 #ifdef Unix # ifdef HAVE_X11 int X11 = NA_LOGICAL; # else int X11 = FALSE <--- missing ; # endif #endif Results in a build error when compiling with no X11 libs, i.e. when configured using: ./configure --with-x=no From janek.musek at guest.arnes.si Thu Nov 6 16:39:41 2008 From: janek.musek at guest.arnes.si (janek musek) Date: Thu, 6 Nov 2008 16:39:41 +0100 Subject: [Rd] 2.8.0 release bugs (PR#13210) In-Reply-To: Message-ID: <000001c94025$e3b6deb0$6432a8c0@uporabnid23742> Dear colleagues, Thank you very much for information, the application of patches will probably help. I apologize for answering delay due to my absence for some days and for bothering you with my asking. I simply followed the suggestion to report the possible troubles during the use of this R release (the only one I must say) and certainly did not intend to cause any inconveniences. Best regards, Prof. Dr. Janek Musek From jeff.a.ryan at gmail.com Thu Nov 6 23:28:56 2008 From: jeff.a.ryan at gmail.com (Jeff Ryan) Date: Thu, 6 Nov 2008 16:28:56 -0600 Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? In-Reply-To: <20368695.post@talk.nabble.com> References: <20368695.post@talk.nabble.com> Message-ID: Marcel, If you are writing the C code from scratch, take a look at either .Call or .External, as both make no copies of the input objects, and require no explicit conversion to the underlying storage type (numeric/integer/etc) within the function call. An even greater benefit is that you will also have access to the actual R objects within C. Jeff On Thu, Nov 6, 2008 at 2:05 PM, MarcelK wrote: > > Hello, > > I'm trying to create my own C code for use within R. While optimizing the > code I've noticed that even while only using pointers to get my data to C > the time needed still depends on data (vector) size. > > To test this, I've created an empty C function to which I've send vectors > containing various sizes of elements. The time needed for each call is > measured and plotted. I would expect a flat line (a little above y=0) since > the only thing send are pointers. What I do not expect is to see a linear > climbing line when the vector size increases. Initializing the vectors isn't > being measured, only the '.C' call to an empty C function, see below. > > Is there anything I'm missing that can explain this input-size dependent > latency? The only reason I can think of is that these vectors are being > copied along the way. > > What follows is both the R and C code which I use only for testing and a > plot of both measurements with DUP=TRUE and DUP=FALSE: > > (RED: DUP=FALSE, GREEN: DUP=TRUE) > http://www.nabble.com/file/p20368695/CandR.png > > > R code: > ---------- > # sequence from 512 to 2^23 with 2^17 stepsize > a <- seq(512, 2^23, 2^17) > # storage for wall time > h <- length(a); j <- length(a) > for (i in 1:length(a)) { > x <- as.double(1:a[i]) > y <- as.double(x) > # system.time()[3] is (actual) wall time > h[i] <- system.time(.C("commTest", x, y, DUP=FALSE))[3] > j[i] <- system.time(.C("commTest", x, y, DUP=TRUE))[3] > x <- 0 > y <- 0 > } > # plot: > plot(a, h, type="l", col="red", xlab="Vector Size -->", ylab="Time in > Seconds -->"); lines(a, j, col="green") > > > C code: > ----------- > #include > extern "C" { > void commTest(double* a, double* b); > } > > /* > * Empty function > * Just testing communication costs between R --> C > */ > void commTest(double* a, double* b) { > /* Do ab-so-lute-ly-nothing.. */ > } > > System Details: > --------------------- > Linux gpu 2.6.18-6-amd64 #1 SMP Thu May 8 06:49:39 UTC 2008 x86_64 GNU/Linux > R version 2.7.1 (2008-06-23) > -- > View this message in context: http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20368695.html > Sent from the R devel mailing list archive at Nabble.com. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.ryan at insightalgo.com ia: insight algorithmics www.insightalgo.com From ripley at stats.ox.ac.uk Thu Nov 6 23:32:13 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Thu, 6 Nov 2008 22:32:13 +0000 (GMT) Subject: [Rd] Compile error when configured with (PR#13256) In-Reply-To: <20081106162503.B53B1282EFF6@mail.pubhealth.ku.dk> References: <20081106162503.B53B1282EFF6@mail.pubhealth.ku.dk> Message-ID: This was fixed in R-patched two weeks ago and is the *third* bug report filed on this topic. Do please follow the FAQ and not report on already reported and already fixed problems (which were not reported in the alpha/beta test period). On Thu, 6 Nov 2008, jon at epcc.ed.ac.uk wrote: > Full_Name: Jon Hill > Version: 2.8.1 > OS: Linux > Submission from: (NULL) (129.215.63.157) > > > A semicolon is missing from src/main/platform.c line 1657 > > #ifdef Unix > # ifdef HAVE_X11 > int X11 = NA_LOGICAL; > # else > int X11 = FALSE <--- missing ; > # endif > #endif > > Results in a build error when compiling with no X11 libs, i.e. when configured > using: > ./configure --with-x=no > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From simon.urbanek at r-project.org Thu Nov 6 23:41:39 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Thu, 6 Nov 2008 17:41:39 -0500 Subject: [Rd] problem packaging S4 class that contains a slot of jobjRef class In-Reply-To: References: Message-ID: <040372AE-A3E4-4AEE-80CF-9E46D7951C06@r-project.org> Adrian, my guess would be that you're trying to crate some Java objects at the top level of your package. That won't work, because R stores a serialized image of created objects for efficiency and hence the reference to any Java objects that you create will disappear as soon as you're done installing the package. When you try to load the package you'll end up with null references for all objects you have attempted to create that way. You have two options to avoid that: 1) create objects at load time - i.e. in the initialization function after you have called .jpackage. Only then is Java up and running so you can safely create Java objects 2) [not recommended] use .jcache to serialize objects you want to keep at the top level after creating them. They will be then lazily deserialized after the package has been loaded. However, this requires all such classes to implement Serializable interface on the Java side and is conceptually not clean, because you have to be careful when your cached serialization goes out of sync with the actual object (see details in the documentation of .jcache). This is just my guess based on the symptoms since I think you actually failed to send us the part of code that triggers the problem. Cheers, Simon On Nov 6, 2008, at 10:04 , Adrian Dragulescu wrote: > > > Hello, > > I'm trying to package some source files that link R to a broker using > a Java API and the rJava package. I am successful doing the > connection > and operate on it using my R code. I would like to package the > files and > release the package. > > I created some S4 classes to hold several Java objects. I use WinXP > and R > 2.7.1. I've searched RSeek and the Wiki for help, but could not > find a > solution. > > Here is my class definition: > twsConnect <- function(...) > new("twsConnect", ...) > > setClass( > Class="twsConnect", > representation=representation( > clientId = "integer", > host = "character", > port = "integer", > reference = "jobjRef"), > prototype=prototype( > clientId = as.integer(0), > host = "", > port = as.integer(7496), > reference = .jnull()) > ) > > setMethod("initialize", "twsConnect", function( > .Object, clientId = 0, host = "", port = 7496, ...) > { > # hook up to the TWS > ref <- .jnew("dev/AAD_Trader", as.integer(clientId), host, > as.integer(port)) > > if (class(ref)[1] != "jobjRef") > stop("Could not connect. Check your settings.") > > .Object at clientId <- as.integer(clientId) > .Object at host <- as.character(host) > .Object at port <- as.integer(port) > .Object at reference <- ref > > .Object > } > ) > > > setMethod("show", "twsConnect", > function(object){ > cat("Object of class \"", class(object), "\":\n", sep="") > lines <- NULL > for (s in slotNames(object)){ > cont <- slot(object, s) > if (is.character(cont))cont <- paste('"', cont, '"', sep="") > if (class(cont)=="jobjRef") cont <- "jobjRef" > lines <- paste(lines, paste(s, " = ", cont, "\n", > sep=""), sep="") > } > cat(lines) > } > ) > > > > I have other files too. Here is the output from package creation: > S:\All\Risk\Software\R\R-2.7.1\bin>Rcmd build --force --binary > H:/user/R/Adrian/RIB/ > * checking for file 'H:/user/R/Adrian/RIB/DESCRIPTION' ... OK > * preparing 'H:/user/R/Adrian/RIB': > * checking DESCRIPTION meta-information ... OK > * removing junk files > * excluding invalid files from 'RIB' > Subdirectory 'R' contains invalid file names: > .make.IB.package.R .utilities.R > * checking for LF line-endings in source and make files > * checking for empty or unneeded directories > WARNING: directory 'RIB/inst/doc' is empty > * building binary distribution > WARNING: some HTML links may not be found > installing R.css in C:/DOCUME~1/e47187/LOCALS~1/Temp/Rinst238480883 > > Using auto-selected zip options '' > > ---------- Making package RIB ------------ > adding build stamp to DESCRIPTION > installing NAMESPACE file and metadata > installing R files > installing inst files > preparing package RIB for lazy loading > Loading required package: rJava > Warning: package 'rJava' was built under R version 2.7.2 > Loading required package: zoo > > Attaching package: 'zoo' > > > The following object(s) are masked from package:base : > > as.Date.numeric > > Creating a new generic function for "summary" in "RIB" > installing man source files > installing indices > installing help >>>> Building/Updating help pages for package 'RIB' > Formats: text html latex example chm > IBrokers-package text html latex example chm > reqAccountUpdates text html latex example chm > reqHistoricalData text html latex example chm > twsConnect text html latex example chm > Note: removing empty section \details > Note: removing empty section \details > twsContract text html latex example chm > twsOrder text html latex example chm > hhc: not found > CHM compile failed: HTML Help Workshop not installed? > adding MD5 sums > > packaged installation of package 'RIB' as RIB_0.1.0.zip > * DONE (RIB) > > Not clean yet, but good for testing. > > So, from R: > >> require("RIB") > Loading required package: RIB > Loading required package: rJava > Loading required package: zoo > > Attaching package: 'zoo' > > > The following object(s) are masked from package:base : > > as.Date.numeric > > Warning message: > package 'rJava' was built under R version 2.7.2 >> tws <- twsConnect() >> tws > Object of class "twsConnect": > clientId = 0 > host = "" > port = 7496 > reference = jobjRef >> tws at reference > [1] "Java-Object" > So I have no connection... > >> tws <- new("twsConnect", 1, "", 7496) > Error in initialize(value, ...) : > cannot use object of class "numeric" in new(): class "twsConnect" > does > not extend that class >> > > but if I source the file: >> source("H:/user/R/Adrian/RIB/R/twsConnect.R") >> tws <- twsConnect() >> tws > Object of class "twsConnect": > clientId = 0 > host = "" > port = 7496 > reference = jobjRef >> >> tws at reference > [1] "Java-Object{dev.AAD_Trader at 12558d6}" >> > Things work as I want, I have the connection. What does source do, > that I > miss when packaging? > > My NAMESPACE file is: > exportPattern("^[^\\.]") > > exportClasses("twsConnect", "twsContract", "twsExecutionFilter", > "twsOrder") > > exportMethods("show") > > My .onLoad function contains ".jpackage(pkgname)". > > I tried to package just the class twsConnect without the slot > reference, > and things worked out fine. I tried to say that twsConnect contains > "jobjRef" but did not have much success. > > > Thanks a lot, > Adrian Dragulescu > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From grey.moran at gmail.com Fri Nov 7 00:53:12 2008 From: grey.moran at gmail.com (Grey Moran Tzamouranis) Date: Thu, 6 Nov 2008 18:53:12 -0500 Subject: [Rd] problems executing a bulk load with SQL server Message-ID: <3c57fdf0811061553s205c8d64j9d8aeb2d8f4cb64b@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From Mark.Bravington at csiro.au Fri Nov 7 00:57:30 2008 From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au) Date: Fri, 7 Nov 2008 10:57:30 +1100 Subject: [Rd] Two minor escaping issues using \preformatted{....} in Rd format In-Reply-To: <491336E1.6010702@web.de> References: <491336E1.6010702@web.de> Message-ID: <62C82B39B8A85E4B95A18F7F7B852F870C6FD5A2@exvic-mbx03.nexus.csiro.au> Hi Peter I've recently run into very similar phenomena, not just in \preformatted. After extensive experimentation, I've found some ugly but effective workarounds. The Rd problems can occur *after* either a backslash or a left brace; that's a necessary but not sufficient condition, as they only occur with certain following characters or sequences. For (one) example, interesting things happen if you try to output the string "\code" in certain parts of your documentation, whereas "\dode" is fine; I speculate that Rdconv may use global searches for "\code" which ignore context. My ugly workarounds are as follows: In verbatim-like modes (eg \preformatted, USAGE, EXAMPLES, and \code fragments), insert \link{} after a backslash or left brace. In text-like modes, insert \enc{}{} after the backslash or left brace. This seems to work very generally. AFAICS the insertions leave no trace in the final help products, but they are not strictly necessary in all cases; it does depend on the following character(s), as you've noted. I'm not 100% sure what all the dangerous following characters are. The only problem with the verbatim-mode fix is that it will trigger a "missing link:" warning during RCMD CHECK. The missing link in question is empty, but doesn't cause any problem in the final documentation (text, html, or pdf). Based on recent experience, this is probably OK with the CRAN maintainers if you explain why, but in the longer term I guess it would be good if the fundamental conversion issues were addressed. The absolutely simplest way to get things to behave for now, might be (i) for writers to use the above fixes, and (ii) for RCMD CHECK to not issue warnings for missing links *iff* the link is empty. Presumably this would not appeal to the pure of heart, but it would save anyone having to crawl through the bowels of Rdconv... HTH Mark -- Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 -----Original Message----- From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf Of Peter Ruckdeschel Sent: Friday, 7 November 2008 5:27 AM To: r-devel at r-project.org Subject: [Rd] Two minor escaping issues using \preformatted{....} in Rd format Hi r-devels, I have two minor problems with special characters in Rd files when used within a \preformatted{} markup command: ------------------------------------------------------ 1. issue: backslash + single brace ------------------------------------------------------ I would like to write "\\\}" to produce \} on output (documenting the need to escape the brace once again before TeX-ing it); this fails if there is no space between the second and third backslash, but works if there is a space, but this produces \ } then.... ------------------------------------------------------ 2. issue: backslash + percent sign ------------------------------------------------------ I would like to write "\\\\\%" to give a string argument \\% on output; this is needed for documenting how to register special operators to TeX package 'listings'. Again this fails, while "\\\\ \%" works. In neither case 1 or 2 the standard TeX trick to produce a linebreak in the source without producing a space on output helps, i.e. \\% \} resp. \\\\% \% both produce valid code [the resp. first % is read as a comment sign] but also insert a non-intended space in the output. Any idea how to circumvent this? Best, Peter ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel From murdoch at stats.uwo.ca Fri Nov 7 02:32:18 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 06 Nov 2008 20:32:18 -0500 Subject: [Rd] Two minor escaping issues using \preformatted{....} in Rd format In-Reply-To: <491336E1.6010702@web.de> References: <491336E1.6010702@web.de> Message-ID: <49139AA2.1030803@stats.uwo.ca> On 06/11/2008 1:26 PM, Peter Ruckdeschel wrote: > Hi r-devels, > > I have two minor problems with special characters in Rd files when > used within a \preformatted{} markup command: > > ------------------------------------------------------ > 1. issue: backslash + single brace > ------------------------------------------------------ > > I would like to write "\\\}" to produce \} on output (documenting > the need to escape the brace once again before TeX-ing it); > this fails if there is no space between the second and third > backslash, but works if there is a space, but this produces > \ } then.... We have started some work on overhauling Rd processing. Your comments on the early work would be welcome. These might appear in 2.9.0, or maybe later, or maybe not at all. You can read about them on developer.r-project.org. In this case, what you want to write would be supported. Mark's workaround would no longer work, because \link{} wouldn't be recognized within \preformatted. > ------------------------------------------------------ > 2. issue: backslash + percent sign > ------------------------------------------------------ > > I would like to write "\\\\\%" to give a string argument \\% on > output; this is needed for documenting how to register special > operators to TeX package 'listings'. > Again this fails, while "\\\\ \%" works. > > In neither case 1 or 2 the standard TeX trick to produce a > linebreak in the source without producing a space on output > helps, i.e. > > \\% > \} > > resp. > \\\\% > \% > > both produce valid code [the resp. first % is read as a comment > sign] but also insert a non-intended space in the output. Those would probably still insert spaces under the proposed changes. Duncan Murdoch > Any idea how to circumvent this? > Best, Peter > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From p.dalgaard at biostat.ku.dk Fri Nov 7 08:25:35 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Fri, 07 Nov 2008 08:25:35 +0100 Subject: [Rd] Axis gives error message (PR#13259) In-Reply-To: <20081106202512.81934282EFF0@mail.pubhealth.ku.dk> References: <20081106202512.81934282EFF0@mail.pubhealth.ku.dk> Message-ID: <4913ED6F.7090809@biostat.ku.dk> ggrothendieck at gmail.com wrote: > Full_Name: G. Grothendieck > Version: R version 2.8.0 Patched (2008-10-21 r46766) > OS: Vista > Submission from: (NULL) (69.63.56.110) > > > Was posted here on r-devel > > https://stat.ethz.ch/pipermail/r-devel/2008-November/051173.html > > but got no replies. The list probably knows you well enough to expect that you'd come up with a patch for axis.date... The issue is that it is clipping the "at" values z <- z[z >= range[1] & z <= range[2]] but not the corresponding "labels". A slight complication is that labels can be absent or TRUE/FALSE. -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From m_kempenaar at planet.nl Fri Nov 7 09:18:45 2008 From: m_kempenaar at planet.nl (MarcelK) Date: Fri, 7 Nov 2008 00:18:45 -0800 (PST) Subject: [Rd] .C(..., DUP=FALSE) memory costs depending on input size? In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D7001DE979@NA-PA-VBE03.na.tibco.com> References: <20368695.post@talk.nabble.com> <77EB52C6DD32BA4D87471DCD70C8D7001DE979@NA-PA-VBE03.na.tibco.com> Message-ID: <20376259.post@talk.nabble.com> Thank you for your answer William. I've tried the parameter NAOK out and this is the result: (RED: FALSE, GREEN: TRUE) http://www.nabble.com/file/p20376259/RandC_2.png As you can see the green line is almost flat now, at least a lot better then when disabling this option. Still there is something causing the line to be not completely flat. Although I suspect some of this is because of the timing function (is there any other, more accurate, timing function in R besides system.time()?) it still looks depending on vector size. Numeric output: NAOK=FALSE: ---------------- [1] 0.000 0.001 0.002 0.003 0.004 0.005 0.006 0.007 0.008 0.009 0.011 0.012 [13] 0.012 0.014 0.014 0.015 0.017 0.018 0.019 0.020 0.021 0.021 0.023 0.024 [25] 0.025 0.026 0.027 0.028 0.029 0.030 0.031 0.032 0.033 0.034 0.035 0.036 [37] 0.038 0.038 0.039 0.041 0.042 0.043 0.044 0.045 0.046 0.046 0.048 0.049 [49] 0.050 0.050 0.052 0.053 0.054 0.055 0.056 0.057 0.058 0.060 0.060 0.061 [61] 0.063 0.063 0.065 0.065 NAOK=TRUE: --------------- [1] 0.000 0.000 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001 [13] 0.002 0.002 0.002 0.002 0.002 0.002 0.002 0.003 0.002 0.003 0.002 0.002 [25] 0.003 0.003 0.003 0.003 0.003 0.003 0.004 0.003 0.004 0.003 0.004 0.004 [37] 0.004 0.004 0.004 0.004 0.004 0.004 0.005 0.005 0.005 0.005 0.005 0.005 [49] 0.005 0.006 0.006 0.005 0.006 0.006 0.006 0.006 0.006 0.006 0.006 0.007 [61] 0.006 0.007 0.007 0.008 Input sizes: ------------- [1] 512 131584 262656 393728 524800 655872 786944 918016 1049088 [10] 1180160 1311232 1442304 1573376 1704448 1835520 1966592 2097664 2228736 [19] 2359808 2490880 2621952 2753024 2884096 3015168 3146240 3277312 3408384 [28] 3539456 3670528 3801600 3932672 4063744 4194816 4325888 4456960 4588032 [37] 4719104 4850176 4981248 5112320 5243392 5374464 5505536 5636608 5767680 [46] 5898752 6029824 6160896 6291968 6423040 6554112 6685184 6816256 6947328 [55] 7078400 7209472 7340544 7471616 7602688 7733760 7864832 7995904 8126976 [64] 8258048 Thanks again for the advice, helped me a lot. And yes, I will be looking at using .Call() or .External(), but since the learning curve is a bit steep and I'm currently only making a proof of concept, .C() will do fine for now. (P.S. I posted this using Nabble, so layout in e-mail might be a bit awkward..) William Dunlap wrote: > > > Does using NAOK=TRUE in the .C() help? That would avoid > an NA-scan of the input vectors. > > Bill Dunlap > TIBCO Spotfire Inc > wdunlap tibco.com > > -- View this message in context: http://www.nabble.com/.C%28...%2C-DUP%3DFALSE%29-memory-costs-depending-on-input-size--tp20368695p20376259.html Sent from the R devel mailing list archive at Nabble.com. From ct529 at york.ac.uk Fri Nov 7 11:56:42 2008 From: ct529 at york.ac.uk (Corrado) Date: Fri, 7 Nov 2008 10:56:42 +0000 Subject: [Rd] Solved (RODBC): was Re: *** buffer overflow detected ***: /usr/lib64/R/bin/exec/R terminated on R 2.6.2 to 2.8.0: logging a bug? In-Reply-To: <490B58CE.6070701@stats.uwo.ca> References: <200810311117.17677.ct529@york.ac.uk> <200810311657.58146.ct529@york.ac.uk> <490B58CE.6070701@stats.uwo.ca> Message-ID: <200811071056.43035.ct529@york.ac.uk> Dear friends, problem solved after talking to the unixODBC maintainer. The problem is that the odbc driver (not unixODBC). The standard Mandriva installation uses the old default postgresql driver, which was embedded in the unixODBC, and not the newer odbc driver. As long as you update the driver (by downloading, building and installing manually) to the appropriate version: Here is the most important link: http://psqlodbc.projects.postgresql.org/ Is it the case of putting note somewhere for other Mandriva users? On Friday 31 October 2008 19:13:18 Duncan Murdoch wrote: > On 10/31/2008 12:57 PM, Corrado wrote: > > On Friday 31 October 2008 16:29:13 you wrote: > >> See Prof. Ripley's message. RODBC is passing a buffer and buffer size > >> to the ODBC driver, and that driver is overflowing the buffer. You > >> could probably hide this bug by making the buffer larger, but the real > >> fix is for the driver to take account of the buffer size it is being > >> given. > > > > 1) How do you make the buffer bigger? Are we talking about increasing the > > -- --param=ssp-buffer-size=4 at compilation time? would that solve the > > problem, in your opinion? > > I don't know. I wouldn't do that. > > > 2) Why is this problem RODBC specific, if the problem is in the odbc > > driver? > > Because the other packages pass bigger buffers, or generate different > messages? > > I > > > do agree that RODBC passes buffer / buffer size, but why do other > > applications work and RODBC does not? If the problem was with the driver, > > then every other application linking to the same database through the > > same driver would have the same problem, unless the other applications > > pass the call (+ buffer / buffer size) in a different way. > > Or if they ask the driver to do different things, or pass a different > size of buffer, etc. The fact that this only occurs for RODBC suggests > there's a problem there, but the fact that the driver is using sprintf > on a limited size of buffer is far stronger evidence that the problem is > in the driver. > > Duncan Murdoch > > > Please, keep in mind I am just trying to solve a problem that other > > people may have, because I am using standard installation. > > > > Best, > > -- > > Corrado Topi > > > > Global Climate Change & Biodiversity Indicators > > Area 18,Department of Biology > > University of York, York, YO10 5YW, UK > > Phone: + 44 (0) 1904 328645, E-mail: ct529 at york.ac.uk > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel -- Corrado Topi Global Climate Change & Biodiversity Indicators Area 18,Department of Biology University of York, York, YO10 5YW, UK Phone: + 44 (0) 1904 328645, E-mail: ct529 at york.ac.uk From ripley at stats.ox.ac.uk Fri Nov 7 12:32:30 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 7 Nov 2008 11:32:30 +0000 (GMT) Subject: [Rd] Solved (RODBC): was Re: *** buffer overflow detected ***: /usr/lib64/R/bin/exec/R terminated on R 2.6.2 to 2.8.0: logging a bug? In-Reply-To: <200811071056.43035.ct529@york.ac.uk> References: <200810311117.17677.ct529@york.ac.uk> <200810311657.58146.ct529@york.ac.uk> <490B58CE.6070701@stats.uwo.ca> <200811071056.43035.ct529@york.ac.uk> Message-ID: On Fri, 7 Nov 2008, Corrado wrote: > Dear friends, > > problem solved after talking to the unixODBC maintainer. > > The problem is that the odbc driver (not unixODBC). The standard Mandriva > installation uses the old default postgresql driver, which was embedded in > the unixODBC, and not the newer odbc driver. > > As long as you update the driver (by downloading, building and installing > manually) to the appropriate version: > > Here is the most important link: http://psqlodbc.projects.postgresql.org/ > > Is it the case of putting note somewhere for other Mandriva users? You mean as in the RODBC README file which says 'this driver seems unreliable (see the ChangeLog)'? You *had* been warned, and no one who does not use Mandriva would have any idea that they were not using PostgreSQL's current driver (and that is the driver described in the RODBC README). > > On Friday 31 October 2008 19:13:18 Duncan Murdoch wrote: >> On 10/31/2008 12:57 PM, Corrado wrote: >>> On Friday 31 October 2008 16:29:13 you wrote: >>>> See Prof. Ripley's message. RODBC is passing a buffer and buffer size >>>> to the ODBC driver, and that driver is overflowing the buffer. You >>>> could probably hide this bug by making the buffer larger, but the real >>>> fix is for the driver to take account of the buffer size it is being >>>> given. >>> >>> 1) How do you make the buffer bigger? Are we talking about increasing the >>> -- --param=ssp-buffer-size=4 at compilation time? would that solve the >>> problem, in your opinion? >> >> I don't know. I wouldn't do that. >> >>> 2) Why is this problem RODBC specific, if the problem is in the odbc >>> driver? >> >> Because the other packages pass bigger buffers, or generate different >> messages? >> >> I >> >>> do agree that RODBC passes buffer / buffer size, but why do other >>> applications work and RODBC does not? If the problem was with the driver, >>> then every other application linking to the same database through the >>> same driver would have the same problem, unless the other applications >>> pass the call (+ buffer / buffer size) in a different way. >> >> Or if they ask the driver to do different things, or pass a different >> size of buffer, etc. The fact that this only occurs for RODBC suggests >> there's a problem there, but the fact that the driver is using sprintf >> on a limited size of buffer is far stronger evidence that the problem is >> in the driver. >> >> Duncan Murdoch >> >>> Please, keep in mind I am just trying to solve a problem that other >>> people may have, because I am using standard installation. >>> >>> Best, >>> -- >>> Corrado Topi >>> >>> Global Climate Change & Biodiversity Indicators >>> Area 18,Department of Biology >>> University of York, York, YO10 5YW, UK >>> Phone: + 44 (0) 1904 328645, E-mail: ct529 at york.ac.uk >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Corrado Topi > > Global Climate Change & Biodiversity Indicators > Area 18,Department of Biology > University of York, York, YO10 5YW, UK > Phone: + 44 (0) 1904 328645, E-mail: ct529 at york.ac.uk > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From gml4410 at ggr.co.uk Fri Nov 7 14:45:03 2008 From: gml4410 at ggr.co.uk (gml4410 at ggr.co.uk) Date: Fri, 7 Nov 2008 14:45:03 +0100 (CET) Subject: [Rd] R 2.8.0. INSTALL script error on Solaris2.8 (PR#13261) Message-ID: <20081107134503.91636282EFF6@mail.pubhealth.ku.dk> Full_Name: Gordon Lack Version: 2.8.0 OS: Solaris 2.8 Submission from: (NULL) (198.28.92.5) The INSTALL.in script in src/scripts has this at line 620: if ! test -f "${R_INCLUDE_DIR}/R.h" ; then That fails to run under sh on Solaris (itis OK in bash, which is why it runs OK on Linux). The correct sh syntax is: if test ! -f "${R_INCLUDE_DIR}/R.h" ; then i.e. test understands that ! means not, but the if statement in sh doesn't. The result of this is that you get error messages tryign to install extensions on Solaris. /the/path/to/my/installation/2.8.0/lib/R/bin/INSTALL: !: not found From degras at uchicago.edu Fri Nov 7 18:40:10 2008 From: degras at uchicago.edu (degras at uchicago.edu) Date: Fri, 7 Nov 2008 18:40:10 +0100 (CET) Subject: [Rd] Problems with packages fda and splines (PR#13263) Message-ID: <20081107174010.F2DEA282C765@mail.pubhealth.ku.dk> Full_Name: David D Degras Version: 2.8.0 OS: Mac OS X Submission from: (NULL) (128.135.239.11) I have recently installed the version 2.8.0 of R along with package fda (v 2.0.2) and its dependencies (including package splines v. 2.8.0). Here are my problems: 1) The package splines should feature functions such a predict.bs, predict.bSpline and such and it does not! I can make calls to bs, ns, and interpSpline but not to any predicting function. Example: > library(splines) > predict.bs Erreur : objet "predict.bs" non trouv? # in english: object "predict.bs" not found Also, I cannot track the package splines on the CRAN website. Why is that? 2) Package fda: it does not handle at all NAs although promising to. I have met this problem using Data2fd and project.basis as well. An example script is enclosed at the end of this email. Can you help on this ? Thanks, David %%%%%%%%%%%%%%%%%%%%%%%%%%%%% R SCRIPT for Data2fd with NAs %%%%%%%%%%%%%%%%%%%%%%%%%%%%% > library(fda) > y=runif(10) > x=Data2fd(1:10,y) # creates functional object in B-spline basis Warning message: In smooth.basis(argvals, y, fdP, wtvec = w, fdnames = fdnames) : The number of basis functions = 12 exceeds 10 = the number of points to be smoothed. With no smoothing (lambda = 0), this will produce a perfect fit to data that typically has wild excursions between data points. > x$coefs # here it works because no NAs [,1] [1,] 0.9193563 [2,] 0.1590327 [3,] 0.6441482 [4,] 1.1257380 [5,] 0.1234022 [6,] 0.7228168 [7,] 0.8709656 [8,] -0.3634714 [9,] 0.9097221 [10,] 1.1726878 [11,] 0.4130424 [12,] 0.3122870 > y[3]=NA # create a NA > x=Data2fd(1:10,y) Warning message: In smooth.basis(argvals, y, fdP, wtvec = w, fdnames = fdnames) : The number of basis functions = 12 exceeds 10 = the number of points to be smoothed. With no smoothing (lambda = 0), this will produce a perfect fit to data that typically has wild excursions between data points. > x$coefs # vector of NAs because y[3]=NA [,1] [1,] NA [2,] NA [3,] NA [4,] NA [5,] NA [6,] NA [7,] NA [8,] NA [9,] NA [10,] NA [11,] NA [12,] NA From spencer.graves at pdf.com Fri Nov 7 21:15:53 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Fri, 07 Nov 2008 12:15:53 -0800 Subject: [Rd] Problems with packages fda and splines (PR#13263) In-Reply-To: <20081107174010.F2DEA282C765@mail.pubhealth.ku.dk> References: <20081107174010.F2DEA282C765@mail.pubhealth.ku.dk> Message-ID: <4914A1F9.8050106@pdf.com> Hello, David: Thanks for the comments about NA problems in 'fda'. I'll look into this and get back with you. Spencer degras at uchicago.edu wrote: > Full_Name: David D Degras > Version: 2.8.0 > OS: Mac OS X > Submission from: (NULL) (128.135.239.11) > > > I have recently installed the version 2.8.0 of R along with package fda (v > 2.0.2) > and its dependencies (including package splines v. 2.8.0). > > Here are my problems: > > 1) The package splines should feature functions such a predict.bs, > predict.bSpline and such and it does not! I can make calls to bs, ns, and > interpSpline but not to any predicting function. > Example: > >> library(splines) >> predict.bs >> > Erreur : objet "predict.bs" non trouv? # in english: object "predict.bs" not > found > > Also, I cannot track the package splines on the CRAN website. Why is that? > > 2) Package fda: it does not handle at all NAs although promising to. > I have met this problem using Data2fd and project.basis as well. > An example script is enclosed at the end of this email. > > Can you help on this ? > > Thanks, > > David > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%% > R SCRIPT for Data2fd with NAs > %%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > >> library(fda) >> y=runif(10) >> x=Data2fd(1:10,y) # creates functional object in B-spline basis >> > Warning message: > In smooth.basis(argvals, y, fdP, wtvec = w, fdnames = fdnames) : > The number of basis functions = 12 exceeds 10 = the number of points to be > smoothed. With no smoothing (lambda = 0), this will produce a perfect fit to > data that typically has wild excursions between data points. > >> x$coefs # here it works because no NAs >> > [,1] > [1,] 0.9193563 > [2,] 0.1590327 > [3,] 0.6441482 > [4,] 1.1257380 > [5,] 0.1234022 > [6,] 0.7228168 > [7,] 0.8709656 > [8,] -0.3634714 > [9,] 0.9097221 > [10,] 1.1726878 > [11,] 0.4130424 > [12,] 0.3122870 > >> y[3]=NA # create a NA >> x=Data2fd(1:10,y) >> > Warning message: > In smooth.basis(argvals, y, fdP, wtvec = w, fdnames = fdnames) : > The number of basis functions = 12 exceeds 10 = the number of points to be > smoothed. With no smoothing (lambda = 0), this will produce a perfect fit to > data that typically has wild excursions between data points. > >> x$coefs # vector of NAs because y[3]=NA >> > [,1] > [1,] NA > [2,] NA > [3,] NA > [4,] NA > [5,] NA > [6,] NA > [7,] NA > [8,] NA > [9,] NA > [10,] NA > [11,] NA > [12,] NA > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From timhesterberg at gmail.com Fri Nov 7 22:35:12 2008 From: timhesterberg at gmail.com (timhesterberg at gmail.com) Date: Fri, 7 Nov 2008 22:35:12 +0100 (CET) Subject: [Rd] barplot can put legend in wrong place, request option to override that (PR#13265) Message-ID: <20081107213513.00677283417B@mail.pubhealth.ku.dk> This in an enhancement requestion, to add the capability to pass arguments through barplot() to legend(). I've created a version that does this. # Run this code; notice that the legend # is superposed over one bar: barplot(height = cbind(x = c(465,91) / 465 * 100, y = c(840,200) / 840 * 100, z = c(37,17) / 37 * 100), beside = FALSE, width = c(465, 840, 37), col = c(1, 2), legend.text = c("A", "B")) # It would be nice to move the legend to # the top left, where there is room. # barplot() doesn't support this. # Below are diffs for a patched # version that adds an 'args.legend' argument, e.g. barplot(height = cbind(x = c(465,91) / 465 * 100, y = c(840,200) / 840 * 100, z = c(37,17) / 37 * 100), beside = FALSE, width = c(465, 840, 37), col = c(1, 2), legend.text = c("A", "B"), args.legend = list(x = "topleft")) # Check that some of the other arguments are passed without conflict: barplot(height = cbind(x = c(465,91) / 465 * 100, y = c(840,200) / 840 * 100, z = c(37,17) / 37 * 100), beside = FALSE, width = c(465, 840, 37), col = c(1, 2), legend.text = c("A", "B"), args.legend = list(x = 35, y=140, xjust=0, yjust=.5, lty=2)) $ diff -c barplot.R barplot2.R *** barplot.R Mon Aug 11 02:51:52 2008 --- barplot2.R Fri Nov 7 11:52:00 2008 *************** *** 25,31 **** xlim = NULL, ylim = NULL, xpd = TRUE, log = "", axes = TRUE, axisnames = TRUE, cex.axis = par("cex.axis"), cex.names = par("cex.axis"), ! inside = TRUE, plot = TRUE, axis.lty = 0, offset = 0, add = FALSE, ...) { if (!missing(inside)) .NotYetUsed("inside", error = FALSE)# -> help(.) --- 25,32 ---- xlim = NULL, ylim = NULL, xpd = TRUE, log = "", axes = TRUE, axisnames = TRUE, cex.axis = par("cex.axis"), cex.names = par("cex.axis"), ! inside = TRUE, plot = TRUE, axis.lty = 0, offset = 0, add = FALSE, ! args.legend = NULL, ...) { if (!missing(inside)) .NotYetUsed("inside", error = FALSE)# -> help(.) *************** *** 176,184 **** angle <- rev(angle) } xy <- par("usr") ! legend(xy[2] - xinch(0.1), xy[4] - yinch(0.1), ! legend = legend.text, angle = angle, density = density, ! fill = legend.col, xjust = 1, yjust = 1) } title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) if(axes) axis(if(horiz) 1 else 2, cex.axis = cex.axis, ...) --- 177,197 ---- angle <- rev(angle) } xy <- par("usr") ! if(is.null(args.legend)) { ! legend(xy[2] - xinch(0.1), xy[4] - yinch(0.1), ! legend = legend.text, angle = angle, density = density, ! fill = legend.col, xjust = 1, yjust = 1) ! } else { ! args.legend1 <- list(x = xy[2] - xinch(0.1), ! y = xy[4] - yinch(0.1), ! legend = legend.text, ! angle = angle, ! density = density, ! fill = legend.col, ! xjust = 1, yjust = 1) ! args.legend1[names(args.legend)] <- args.legend ! do.call("legend", args.legend1) ! } } title(main = main, sub = sub, xlab = xlab, ylab = ylab, ...) if(axes) axis(if(horiz) 1 else 2, cex.axis = cex.axis, ...) $ diff -c barplot.Rd barplot2.Rd *** barplot.Rd Mon Sep 24 19:05:10 2007 --- barplot2.Rd Fri Nov 7 13:22:22 2008 *************** *** 22,28 **** axes = TRUE, axisnames = TRUE, cex.axis = par("cex.axis"), cex.names = par("cex.axis"), inside = TRUE, plot = TRUE, axis.lty = 0, offset = 0, ! add = FALSE, \dots) } \arguments{ \item{height}{either a vector or matrix of values describing the --- 22,28 ---- axes = TRUE, axisnames = TRUE, cex.axis = par("cex.axis"), cex.names = par("cex.axis"), inside = TRUE, plot = TRUE, axis.lty = 0, offset = 0, ! add = FALSE, args.legend = NULL, \dots) } \arguments{ \item{height}{either a vector or matrix of values describing the *************** *** 105,110 **** --- 105,113 ---- relative to the x axis.} \item{add}{logical specifying if bars should be added to an already existing plot; defaults to \code{FALSE}.} + \item{args.legend}{list of additional arguments to pass to + \code{\link{legend()}}; names of the list are used as argument + names. Only used if \code{legend.text} is supplied.} \item{\dots}{arguments to be passed to/from other methods. For the default method these can include further arguments (such as \code{axes}, \code{asp} and \code{main}) and graphical rocket at rocket1:~/R/bugs/barplot$ --please do not edit the information below-- Version: platform = i386-apple-darwin8.11.1 arch = i386 os = darwin8.11.1 system = i386, darwin8.11.1 status = major = 2 minor = 8.0 year = 2008 month = 10 day = 20 svn rev = 46754 language = R version.string = R version 2.8.0 (2008-10-20) Locale: C Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base [[alternative HTML version deleted]] From jayoung at fhcrc.org Sat Nov 8 01:00:08 2008 From: jayoung at fhcrc.org (jayoung at fhcrc.org) Date: Sat, 8 Nov 2008 01:00:08 +0100 (CET) Subject: [Rd] geeglm crashes if there are no datapoints in predictor's first level (PR#13266) Message-ID: <20081108000008.F26ED282C765@mail.pubhealth.ku.dk> Hi, I managed to make R core dump (linux and Mac OSX versions), but I think I've figured out why. First, here's the message I get on core dump (on linux - no message on Mac): R: ../inst/include/tnt/fmat.h:529: TNT::Vector TNT::matmult(const TNT::Fortran_Matrix&, const TNT::Vector&) [with T = double]: Assertion `A.num_cols() == x.dim()' failed. Abort (core dumped) Second, here's the command: mygeeglm<- geeglm(outcome ~ input , data=mydata, id=mydata$group) Third, my explanation (the dataset is pasted at the very bottom) - initially, mydata$input was an ordered factor, with levels "Med", "Low", "High" BUT the data did not contain any datapoints with value "Med" (yes, I know I shouldn't have used that as input!). I'm pretty sure the absence of datapoints in that first category is what's causing the crash, because when I change the levels of the factor to reflect the datapoints remaining (levels "Low", "High") the geeglm command ran just fine. So it'd be great if geeglm (or whatever function it's calling) could check for stupid mistakes in the input data like the one I was making, and report an error, rather than causing R to crash. Thanks, Janet Young ------------------------------------------------------------------- Dr. Janet Young Fred Hutchinson Cancer Research Center 1100 Fairview Avenue N., C3-168, P.O. Box 19024, Seattle, WA 98109-1024, USA. tel: (206) 667 1471 fax: (206) 667 6524 email: jayoung at fhcrc.org http://www.fhcrc.org/labs/trask/ ------------------------------------------------------------------- > mydata group outcome input 1 bA175B9 0.99370982 High 2 bA322N21 0.58099071 High 3 bA322N21 -0.05601471 High 4 bA322N21 -0.01608595 High 5 bA322N21 -0.65053824 High 6 bA322N21 -0.05417095 High 7 bA382M16 0.01030286 High 8 bA396D18 0.25673448 High 9 bA415J8 -1.04672184 High 10 bA421E17 -1.30500465 High 11 bA454L1 -0.65803623 High 12 bA47A4 3.38755577 High 13 bA552M11 -0.06518991 High 14 bA552M11 0.11066039 High 15 bA552M11 0.14413606 High 16 bA552M11 0.07093663 High 17 bA552M11 0.27674192 High 18 bA552M11 0.26482473 High 19 bA90O23 0.18827961 High 20 dJ1071N3 -0.22666352 High 21 dJ1126H10 -0.34280590 High 22 dJ21O18 -0.94399366 Low 23 dJ329E20 -0.22666352 High 24 dJ533D7 0.58099071 High 25 dJ533D7 -0.05601471 High 26 dJ533D7 -0.01608595 High 27 dJ533D7 -0.65053824 High 28 dJ580L15 -0.40615304 High 29 dJ580L15 0.54838865 High 30 dJ580L15 0.20731824 High 31 dJ655N15 -0.63766633 Low 32 dJ65J11 -1.44140328 Low 33 dJ836N10 -0.06518991 High 34 dJ836N10 0.07093663 High 35 dJ836N10 0.27674192 High From kevin.shook at usask.ca Sat Nov 8 20:35:13 2008 From: kevin.shook at usask.ca (kevin.shook at usask.ca) Date: Sat, 8 Nov 2008 20:35:13 +0100 (CET) Subject: [Rd] Bug in package iid.test (PR#13268) Message-ID: <20081108193513.3875E282EF48@mail.pubhealth.ku.dk> Full_Name: Kevin Shook Version: 2.7.1 OS: Ubuntu 8.01 Submission from: (NULL) (71.17.167.188) I'm having a problem installing the package iid.test. I get the following message: >>> Building/Updating help pages for package 'iid.test' Formats: text html latex example Note: unmatched right brace in file 'daily.station.records.Rd' on or after line 29 daily.station.records text html latex example Note: unmatched right brace in file 'iid.test.Rd' on or after line 30 iid.test text html latex example Note: unmatched right brace in file 'n.records.Rd' on or after line 23 n.records text html latex example I checked the source code and the lines do appear to have extra '}' characters. However, I'm not skilled enough to install from the edited filed. Kevin Shook From ggrothendieck at gmail.com Sun Nov 9 17:11:01 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sun, 9 Nov 2008 11:11:01 -0500 Subject: [Rd] Locating MiKTeX Message-ID: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> I came across this program to locate MiKTeX file: http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html If the exe of this were included with R then it seems it might provide a reliable way to locate MiKTeX which we don't currently have since AFAIK there is no adequate registry key for MiKTeX. Since its a tiny program it would not substantially affect the R download. (There is also a perl version of the same program there although it relies on certain perl packages which would also have to be present complicating things.) From spencer.graves at pdf.com Sun Nov 9 17:41:07 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sun, 09 Nov 2008 08:41:07 -0800 Subject: [Rd] Locating MiKTeX In-Reply-To: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> References: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> Message-ID: <491712A3.6040201@pdf.com> Hi, Gabor, et al.: Could you also please ensure 'plflatex wrapper.tex' work with whatever MikTeX installation you include, for 'wrapper.tex' mentioned in the "Submissions" instructions for R News? This bombed for me when I tried it recently, because I was missing multiple LaTeX packages: When I found one, it asked for another that I couldn't easily find. So I did a maximal install of the latest version of MiKTeX. That involved downloading more that a gigabyte of stuff, then cleaning space on my hard drive so I could actually install it. The whole process took several days, in between my other work. It would help if it were all part of the standard install. Thanks, Spencer Gabor Grothendieck wrote: > I came across this program to locate MiKTeX file: > > http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html > > If the exe of this were included with R then it seems it might > provide a reliable way to locate MiKTeX which we don't currently have > since AFAIK there is no adequate registry key for MiKTeX. > Since its a tiny program it would not substantially affect the > R download. > > (There is also a perl version of the same program there although > it relies on certain perl packages which would also have to be > present complicating things.) > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From ggrothendieck at gmail.com Sun Nov 9 18:55:02 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sun, 9 Nov 2008 12:55:02 -0500 Subject: [Rd] Locating MiKTeX In-Reply-To: <491712A3.6040201@pdf.com> References: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> <491712A3.6040201@pdf.com> Message-ID: <971536df0811090955n72d49a91j2d4adc0962489bc2@mail.gmail.com> MiKTeX automatically downloads additional required packages that your *.tex files use. Something is wrong with your installation if it did not try to do that automatically for you. Although the following should not be necessary, if you do want to download and install additional MiKTeX packages yourself without a massive download just invoke the MiKTeX package manager by entering at the Windows command line: mpm or, if you don't have MiKTeX on your path you can run rtools.bat mpm where rtools.bat, which is from http://batchfiles.googlecode.com , will temporarily add MiKTeX to your path so that you can run mpm and other MiKTeX tools. On Sun, Nov 9, 2008 at 11:41 AM, Spencer Graves wrote: > Hi, Gabor, et al.: > Could you also please ensure 'plflatex wrapper.tex' work with whatever > MikTeX installation you include, for 'wrapper.tex' mentioned in the > "Submissions" instructions for R News? > This bombed for me when I tried it recently, because I was missing > multiple LaTeX packages: When I found one, it asked for another that I > couldn't easily find. So I did a maximal install of the latest version of > MiKTeX. That involved downloading more that a gigabyte of stuff, then > cleaning space on my hard drive so I could actually install it. The whole > process took several days, in between my other work. It would help if it > were all part of the standard install. > Thanks, > Spencer > Gabor Grothendieck wrote: >> >> I came across this program to locate MiKTeX file: >> >> http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html >> >> If the exe of this were included with R then it seems it might >> provide a reliable way to locate MiKTeX which we don't currently have >> since AFAIK there is no adequate registry key for MiKTeX. >> Since its a tiny program it would not substantially affect the >> R download. >> >> (There is also a perl version of the same program there although >> it relies on certain perl packages which would also have to be >> present complicating things.) >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From jsnel at few.vu.nl Sun Nov 9 20:35:56 2008 From: jsnel at few.vu.nl (Joris @ VU) Date: Sun, 9 Nov 2008 20:35:56 +0100 Subject: [Rd] problems installing rJava with R-2.8.0 In-Reply-To: <60E734B6-1D34-4C27-8C16-2E07041C07DF@r-project.org> References: <49088674.6090407@klinik.uni-regensburg.de> <60E734B6-1D34-4C27-8C16-2E07041C07DF@r-project.org> Message-ID: Hello Christian, I had the same problem with running install.packages("rJava"), exactly the same error as you. Turned out the solution was changing a 7 into a 6 somewhere ... please allow me to explain :) Of course the first thing I did, and I suppose you did is follow the advice of Simon Urbanek, run "R CMD javareconf" as root, or if that doesn't work "R CMD javareconf -ed". This is the output of that: =============== linux:/usr/lib/jvm # R CMD javareconf -ed *** JAVA_HOME is not a valid path, ignoring Java interpreter : /usr/bin/java Java version : 1.6.0_06 Java home path : /usr/lib/jvm/java-1.6.0-sun-1.6.0.u6/jre Java compiler : /usr/bin/javac Java headers gen.: /usr/bin/javah Java archive tool: /usr/bin/jar Java library path: $(JAVA_HOME)/lib/i386/server:$(JAVA_HOME)/lib/i386:$(JAVA_HOME)/../lib/i386::/usr/java/packages/lib/i386:/lib:/usr/lib JNI linker flags : -L$(JAVA_HOME)/lib/i386/server -L$(JAVA_HOME)/lib/i386 -L$(JAVA_HOME)/../lib/i386 -L -L/usr/java/packages/lib/i386 -L/lib -L/usr/lib -ljvm JNI cpp flags : -I$(JAVA_HOME)/../include -I$(JAVA_HOME)/../include/linux Updating Java configuration in /usr/lib/R Done. =============== Done. That means "everything is ok" ... right? No. Look at the first line ... "*** JAVA_HOME is not a valid path, ignoring". I figured that's odd, I had no trouble running "java" or "javac" on my computer ... so I ran "$JAVA_HOME" =============== linux:/usr/lib/jvm # $JAVA_HOME bash: /usr/lib/jvm/java-1.6.0-sun-1.6.0.u7: No such file or directory =============== Strange, that seemed to be the correct path ... but upon closer inspection I realized I didn't have update 7 but update 6, so the correct path would be "/usr/lib/jvm/java-1.6.0-sun-1.6.0.u6". I used to have 7 (downloaded from the Sun website) but removed it and installed the version from the openSUSE repositories instead, I guess somehow JAVA_HOME was not updated, even after running "update-alternatives --config javac". Exporing JAVA_HOME manually did the trick for me, so running as root: export JAVA_HOME=/usr/lib/jvm/java-1.6.0-sun-1.6.0.u6 Then running "R CMD javareconf " worked without warning this time. And then running R and "install.package("rJava")" worked without trouble. Still I'm curious where that magical config.log file is located, perhaps that would have pointed out my mistake right away. Best, Joris On Wed, Oct 29, 2008 at 17:10, Simon Urbanek wrote: > > On Oct 29, 2008, at 11:51 , Christian Kohler wrote: > >> Dear R-developers, >> >> I am having trouble installing rJava on R 2.8.0 / debian etch. >> >> What goes wrong? >> > > Please send me the config.log. Also make sure you have configured R with > Java support (sudo R CMD javareconf). > > Cheers, > S > > >> >>> install.packages("rJava") >> >> Warning in install.packages("rJava") : >> argument 'lib' is missing: using >> '/nfs/compdiag/package/R/lib/bioconductor/release_2.3/x86_64' >> --- Please select a CRAN mirror for use in this session --- >> Loading Tcl/Tk interface ... done >> trying URL 'http://cran.rakanu.com/src/contrib/rJava_0.6-0.tar.gz' >> Content type 'application/x-gzip' length 234704 bytes (229 Kb) >> opened URL >> ================================================== >> downloaded 229 Kb >> >> * Installing *source* package 'rJava' ... >> checking for gcc... gcc -std=gnu99 >> checking for C compiler default output file name... a.out >> checking whether the C compiler works... yes >> checking whether we are cross compiling... no >> checking for suffix of executables... >> checking for suffix of object files... o >> checking whether we are using the GNU C compiler... yes >> checking whether gcc -std=gnu99 accepts -g... yes >> checking for gcc -std=gnu99 option to accept ISO C89... none needed >> checking how to run the C preprocessor... gcc -std=gnu99 -E >> checking for grep that handles long lines and -e... /bin/grep >> checking for egrep... /bin/grep -E >> checking for ANSI C header files... yes >> checking for sys/wait.h that is POSIX.1 compatible... yes >> checking for sys/types.h... yes >> checking for sys/stat.h... yes >> checking for stdlib.h... yes >> checking for string.h... yes >> checking for memory.h... yes >> checking for strings.h... yes >> checking for inttypes.h... yes >> checking for stdint.h... yes >> checking for unistd.h... yes >> checking for string.h... (cached) yes >> checking sys/time.h usability... yes >> checking sys/time.h presence... yes >> checking for sys/time.h... yes >> checking for unistd.h... (cached) yes >> checking for an ANSI C-conforming const... yes >> checking whether time.h and sys/time.h may both be included... yes >> configure: checking whether gcc -std=gnu99 supports static inline... >> yes >> checking Java support in R... present: >> interpreter : '/usr/lib/jvm/java-1.5.0-sun/jre/bin/java' >> archiver : '/usr/lib/jvm/java-1.5.0-sun/bin/jar' >> compiler : '/usr/lib/jvm/java-1.5.0-sun/bin/javac' >> header prep.: '/usr/lib/jvm/java-1.5.0-sun/bin/javah' >> cpp flags : '-I/usr/lib/jvm/java-1.5.0-sun/include >> -I/usr/lib/jvm/java-1.5.0-sun/include/linux' >> java libs : >> '-L/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64/server >> -L/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/lib/amd64 >> -L/usr/lib/jvm/java-1.5.0-sun-1.5.0.14/jre/../lib/amd64 >> -L/usr/local/lib64 -ljvm' >> checking whether JNI programs can be compiled... yes >> checking JNI data types... configure: error: One or more JNI types >> differ from the corresponding native type. You may need to use >> non-standard compiler flags or a different compiler in order to fix this. >> ERROR: configuration failed for package 'rJava' >> ** Removing >> '/nfs/compdiag/package/R/lib/bioconductor/release_2.3/x86_64/rJava' >> >> The downloaded packages are in >> /nfs/scratch/Rtmp/RtmpUMDzVa/downloaded_packages >> Warning message: >> In install.packages("rJava") : >> installation of package 'rJava' had non-zero exit status >> >> >>> sessionInfo() >> >> R version 2.8.0 (2008-10-20) >> x86_64-unknown-linux-gnu >> >> locale: >> C >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> loaded via a namespace (and not attached): >> [1] tcltk_2.8.0 tools_2.8.0 >> >> >> >> >> >> >> >> >> >> -- >> >> Christian Kohler >> Institute of Functional Genomics >> Computational Diagnostics >> University of Regensburg (BioPark I) >> D-93147 Regensburg (Germany) >> >> Tel. +49 941 943 5055 >> Fax +49 941 943 5020 >> christian.kohler at klinik.uni-regensburg.de >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From spencer.graves at pdf.com Mon Nov 10 20:21:13 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Mon, 10 Nov 2008 11:21:13 -0800 Subject: [Rd] typo in ?pie Message-ID: <491889A9.6050601@pdf.com> Hello: The help page for 'pie' includes "judgements"; the standard spelling does not include "e", as spell checkers have informed me many times. ... in case someone wants to correct that typo. Best Wishes, Spencer sessionInfo() R version 2.8.0 (2008-10-20) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] mgcv_1.4-1 From dankoc at gmail.com Mon Nov 10 20:53:15 2008 From: dankoc at gmail.com (Charles Danko) Date: Mon, 10 Nov 2008 14:53:15 -0500 Subject: [Rd] Dynamic linking to binary code from other packages?? In-Reply-To: <18691.32336.501605.415161@ron.nulle.part> References: <8adccabf0810251305o3ad8483x5de5009605fbdbe1@mail.gmail.com> <18691.32336.501605.415161@ron.nulle.part> Message-ID: <8adccabf0811101153w6a9e93bfvd7a24138f3c6b15b@mail.gmail.com> Dear, R-devel, Thanks very much for the response! Here is what I am trying to do (also listed below in the previous messages): "I am writing a package that needs some C++ functions from an external SDK (Affymetrix fusion). The same functions are already compiled into another package (affxparser)." I've looked through the "Writing R Extensions" manual, and can't find this documented very clearly. A previous question to the list gave me the very kind response pasted below. I've looked at the suggested examples (lme4 using C functions from Matrix). For lme4 to include Matrix C functions, I find it does this: -- lme4 uses the line "LinkingTo" in the description file. -- "Matrix.h" is an include in the C files. Is this all that I need to do to my package? But, of course, the header files still have to be included in the Matrix install to make this work. In the case of Matrix, it looks like the header file is located at: /usr/local/lib/R/site-library/Matrix/include/Matrix.h (under Ubuntu 8.10) How does Matrix knows to export the Matrix.h header file here? What else is the Matrix package doing to allow other packages to share its C functions? I apologize in advance if this is something obvious that I am missing! Thanks, and warmest regards, Charles On Sat, Oct 25, 2008 at 3:15 PM, Dirk Eddelbuettel wrote: > > On 25 October 2008 at 16:05, Charles Danko wrote: > | Dear R-devel, > | > | I am writing a package that needs some C++ functions from an external > | SDK (Affymetrix fusion). The same functions are already compiled into > | another package (affxparser). > | > | Can I dynamically link to the compiled code in affxparser, rather than > | re-compiling these separately into my package? > > Yes. Working examples are lme4 using Matrix. This is documented in the 'R > Extensions' manual. > > | Not a lot of experience on this subject! > > I don't think it is the easiest way around. Maybe start by 'just' > recompiling and relinking. > > Dirk > > -- > Three out of two people have difficulties with fractions. > From plummer at iarc.fr Mon Nov 10 21:59:24 2008 From: plummer at iarc.fr (plummer at iarc.fr) Date: Mon, 10 Nov 2008 21:59:24 +0100 Subject: [Rd] typo in ?pie In-Reply-To: <491889A9.6050601@pdf.com> References: <491889A9.6050601@pdf.com> Message-ID: <1226350764.4918a0acdc5d6@webmail.iarc.fr> My Concise Oxford Dictionary has both spellings. Quoting Spencer Graves : > Hello: > > The help page for 'pie' includes "judgements"; the standard > spelling does not include "e", as spell checkers have informed me many > times. > > ... in case someone wants to correct that typo. > > Best Wishes, > Spencer > > sessionInfo() > R version 2.8.0 (2008-10-20) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > loaded via a namespace (and not attached): > [1] mgcv_1.4-1 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ----------------------------------------------------------------------- This message and its attachments are strictly confidenti...{{dropped:8}} From ripley at stats.ox.ac.uk Mon Nov 10 22:07:44 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 10 Nov 2008 21:07:44 +0000 (GMT) Subject: [Rd] typo in ?pie In-Reply-To: <491889A9.6050601@pdf.com> References: <491889A9.6050601@pdf.com> Message-ID: On Mon, 10 Nov 2008, Spencer Graves wrote: > Hello: > The help page for 'pie' includes "judgements"; the standard spelling > does not include "e", as spell checkers have informed me many times. > ... in case someone wants to correct that typo. >From the OED: judgement, judgment 1. a. The action of trying a cause in a court of justice; trial. (Now rare or merged in 3.) Also applied to trial by battle (quot. 1377: see BATTLE n. 2) or ordeal (Judgement of God). ... (The header of the entry means that 'judgement' is preferred but 'judgment' is an alternative spelling.) So we do not want to change a preferred spelling into an alternative one. (dictionary.reference.com says it is also correct in American but there 'judgment' is preferred and 'judgement' is 'mainly British'.) 'British' spelling is in the majority amongst R-core, and preferred for R documentation (that is in the guidelines somewhere). > Best Wishes, > Spencer > > sessionInfo() > R version 2.8.0 (2008-10-20) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > loaded via a namespace (and not attached): > [1] mgcv_1.4-1 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From spencer.graves at pdf.com Mon Nov 10 23:37:46 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Mon, 10 Nov 2008 14:37:46 -0800 Subject: [Rd] typo in ?pie In-Reply-To: References: <491889A9.6050601@pdf.com> Message-ID: <4918B7BA.2090808@pdf.com> Hi, Prof. Ripley: Thanks for correcting me. Best Wishes, Spencer Prof Brian Ripley wrote: > On Mon, 10 Nov 2008, Spencer Graves wrote: > >> Hello: >> The help page for 'pie' includes "judgements"; the standard >> spelling does not include "e", as spell checkers have informed me >> many times. >> ... in case someone wants to correct that typo. > > From the OED: > > judgement, judgment > > 1. a. The action of trying a cause in a court of justice; trial. (Now > rare or merged in 3.) Also applied to trial by battle (quot. 1377: see > BATTLE n. 2) or ordeal (Judgement of God). > ... > > (The header of the entry means that 'judgement' is preferred but > 'judgment' is an alternative spelling.) > > So we do not want to change a preferred spelling into an alternative > one. (dictionary.reference.com says it is also correct in American but > there 'judgment' is preferred and 'judgement' is 'mainly British'.) > > 'British' spelling is in the majority amongst R-core, and preferred > for R documentation (that is in the guidelines somewhere). > > >> Best Wishes, >> Spencer >> >> sessionInfo() >> R version 2.8.0 (2008-10-20) >> i386-pc-mingw32 >> >> locale: >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United >> States.1252;LC_MONETARY=English_United >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> loaded via a namespace (and not attached): >> [1] mgcv_1.4-1 >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From spencer.graves at pdf.com Tue Nov 11 04:13:21 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Mon, 10 Nov 2008 19:13:21 -0800 Subject: [Rd] Locating MiKTeX In-Reply-To: <971536df0811090955n72d49a91j2d4adc0962489bc2@mail.gmail.com> References: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> <491712A3.6040201@pdf.com> <971536df0811090955n72d49a91j2d4adc0962489bc2@mail.gmail.com> Message-ID: <4918F851.60807@pdf.com> Hi, Gabor: Gabor Grothendieck wrote: > MiKTeX automatically downloads additional required packages > that your *.tex files use. Something is wrong with your installation > if it did not try to do that automatically for you. > > Although the following should not be necessary, if you do > want to download and install additional MiKTeX packages > yourself without a massive download just invoke the > MiKTeX package manager by entering at the Windows > command line: > > mpm > > or, if you don't have MiKTeX on your path you can run > > rtools.bat > mpm > > where rtools.bat, which is from http://batchfiles.googlecode.com , > will temporarily add MiKTeX to your path so that you can run mpm > and other MiKTeX tools. > Thanks. What should I have done to obtain the information you just provided? When 'pdflatex wrapper.tex' failed for me, I tried several things, including consulting my local Info Tech wizards. What you suggest sounds reasonable, except that my attempts to find information like that failed. Thanks again, Spencer > > On Sun, Nov 9, 2008 at 11:41 AM, Spencer Graves wrote: > >> Hi, Gabor, et al.: >> Could you also please ensure 'plflatex wrapper.tex' work with whatever >> MikTeX installation you include, for 'wrapper.tex' mentioned in the >> "Submissions" instructions for R News? >> This bombed for me when I tried it recently, because I was missing >> multiple LaTeX packages: When I found one, it asked for another that I >> couldn't easily find. So I did a maximal install of the latest version of >> MiKTeX. That involved downloading more that a gigabyte of stuff, then >> cleaning space on my hard drive so I could actually install it. The whole >> process took several days, in between my other work. It would help if it >> were all part of the standard install. >> Thanks, >> Spencer >> Gabor Grothendieck wrote: >> >>> I came across this program to locate MiKTeX file: >>> >>> http://docs.miktex.org/2.7/sdk/findfile_8cpp-example.html >>> >>> If the exe of this were included with R then it seems it might >>> provide a reliable way to locate MiKTeX which we don't currently have >>> since AFAIK there is no adequate registry key for MiKTeX. >>> Since its a tiny program it would not substantially affect the >>> R download. >>> >>> (There is also a perl version of the same program there although >>> it relies on certain perl packages which would also have to be >>> present complicating things.) >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> > > From ggrothendieck at gmail.com Tue Nov 11 04:20:30 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Mon, 10 Nov 2008 22:20:30 -0500 Subject: [Rd] Locating MiKTeX In-Reply-To: <4918F851.60807@pdf.com> References: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> <491712A3.6040201@pdf.com> <971536df0811090955n72d49a91j2d4adc0962489bc2@mail.gmail.com> <4918F851.60807@pdf.com> Message-ID: <971536df0811101920x362eee7cm6dcf8b3c9b7e09a4@mail.gmail.com> On Mon, Nov 10, 2008 at 10:13 PM, Spencer Graves wrote: > Thanks. What should I have done to obtain the information you just > provided? Google for MiKTeX Manual and look at the R batch utilities and info at: http://batchfiles.googlecode.com From Mark.Bravington at csiro.au Tue Nov 11 04:39:39 2008 From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au) Date: Tue, 11 Nov 2008 14:39:39 +1100 Subject: [Rd] Locating MiKTeX In-Reply-To: <971536df0811101920x362eee7cm6dcf8b3c9b7e09a4@mail.gmail.com> References: <971536df0811090811p78ef5883haf68eb2492baf622@mail.gmail.com> <491712A3.6040201@pdf.com> <971536df0811090955n72d49a91j2d4adc0962489bc2@mail.gmail.com> <4918F851.60807@pdf.com> <971536df0811101920x362eee7cm6dcf8b3c9b7e09a4@mail.gmail.com> Message-ID: <62C82B39B8A85E4B95A18F7F7B852F870C6FD5BE@exvic-mbx03.nexus.csiro.au> I've recently had a very similar experience to Spencer. The MikTex project page assumes you know what you want; I don't, so it seemed best to download the whole thing. Ouch. Would it be straightforward for Duncan Murdoch to add some brief instructions on "what bit of MikTex to get" to the excellent "Building R for Windows" page? Mark -- Mark Bravington CSIRO Mathematical & Information Sciences Marine Laboratory Castray Esplanade Hobart 7001 TAS ph (+61) 3 6232 5118 fax (+61) 3 6232 5012 mob (+61) 438 315 623 -----Original Message----- From: r-devel-bounces at r-project.org [mailto:r-devel-bounces at r-project.org] On Behalf Of Gabor Grothendieck Sent: Tuesday, 11 November 2008 2:21 PM To: Spencer Graves Cc: r-devel at r-project.org Subject: Re: [Rd] Locating MiKTeX On Mon, Nov 10, 2008 at 10:13 PM, Spencer Graves wrote: > Thanks. What should I have done to obtain the information you just > provided? Google for MiKTeX Manual and look at the R batch utilities and info at: http://batchfiles.googlecode.com ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel From ripley at stats.ox.ac.uk Tue Nov 11 14:23:55 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 11 Nov 2008 13:23:55 +0000 (GMT) Subject: [Rd] RFC: Offline help Message-ID: I had not used offline help for many years, and when I tried to yesterday I found a number of issues (the most important of which is that I couldn't have R_DVIPSCMD="dvips -Pbdr" to send output to my office printer: the lack of error reporting is also problematic, and hid the fact that I don't have a default printer set for lpr, so unadorned 'dvips' does not work). I've patched up the issues I found, but wondered if anyone was indeed making frequent use of offline help? Two other things I am aware of is that there is no documentation on how to use it with MiKTeX on Windows (although it is possible), and that on Unix-alikes it is basically tied to Postscript printing (and PDF printing would be preferred in a number of setups). If it is meeting a need we should keep it, but it seems to me that it should either be phased out (two less things to maintain, as there are two versions) or rewritten to be much more flexible (perhaps most simply by allowing a user-supplied R function to handle processing the .tex file, with utils::texi2dvi being a good start). -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From iago.mosqueira at gmail.com Tue Nov 11 17:50:27 2008 From: iago.mosqueira at gmail.com (Iago Mosqueira) Date: Tue, 11 Nov 2008 17:50:27 +0100 Subject: [Rd] Linking to headers and shared library in another package Message-ID: <4919B7D3.8050105@gmail.com> Hi, A package with some C code needs to use the headers and shared library in another package during installation/compilation. The first one is achieved through the LinkingTo option in DESCRIPTION. For the second a Makevars file with PKG_LIBS=$(R_HOME)/library/firstPkg/libs/firstPkg.so was being used. Problem this is not portable if the firstPkg package is not installed in the library folder inside R_HOME but lives somewhere else. What is the best way for Makevars or configure to find where a package lives? Or is there any other way to make sure the linking step finds where the shared library is located? Apologies if I missed something in the extensions manual, but my limited experience with autoconf might have made me not notice it. Many thanks, Iago From berwin at maths.uwa.edu.au Tue Nov 11 17:50:16 2008 From: berwin at maths.uwa.edu.au (Berwin A Turlach) Date: Wed, 12 Nov 2008 00:50:16 +0800 Subject: [Rd] typo in ?pie In-Reply-To: References: <491889A9.6050601@pdf.com> Message-ID: <20081112005016.0ad5ad15@berwin5> G'day Brian, On Mon, 10 Nov 2008 21:07:44 +0000 (GMT) Prof Brian Ripley wrote: > 'British' spelling is in the majority amongst R-core, and preferred > for R documentation (that is in the guidelines somewhere). I have a vague memory of a discussion that ended with the conclusion that words like "colour" should be spelt "color"; at least in function names and function arguments. IIRC, this was for compatible reasons with S/S-Plus. Does your comment mean that we can send it patches for help pages in which "colour" is spelt "color" (e.g. lines in package:graphics) and such patches would be applied? Sorry, couldn't resist. :) Cheers, Berwin From danielho at stud.ntnu.no Tue Nov 11 19:20:08 2008 From: danielho at stud.ntnu.no (=?ISO-8859-1?Q?Daniel_H=F8yer_Iversen?=) Date: Tue, 11 Nov 2008 19:20:08 +0100 Subject: [Rd] is.matrix Message-ID: a=c(1,1,2); is.matrix(a) gives FALSE is.matrix(t(a)) gives TRUE is.matrix(t(t(a))) gives TRUE Is this correct? Shouldn't all give FALSE? I think is.matrix should give FALSE when dimension is 1*n or n*1. From P.Dalgaard at biostat.ku.dk Tue Nov 11 19:31:17 2008 From: P.Dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Tue, 11 Nov 2008 19:31:17 +0100 Subject: [Rd] is.matrix In-Reply-To: References: Message-ID: <4919CF75.3010202@biostat.ku.dk> Daniel H?yer Iversen wrote: > a=c(1,1,2); > is.matrix(a) gives FALSE > is.matrix(t(a)) gives TRUE > is.matrix(t(t(a))) gives TRUE > > Is this correct? Shouldn't all give FALSE? > I think is.matrix should give FALSE when dimension is 1*n or n*1. No this is correct. is.matrix() returns TRUE if and only if the argument has a two-dimensional 'dim' attribute, and > dim(a) NULL > dim(t(a)) [1] 1 3 > dim(t(t(a))) [1] 3 1 (And is.array() depends on having a 'dim' attribute of positive length, so > dim(a) <- 3 > is.matrix(a) [1] FALSE > is.array(a) [1] TRUE ) -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From ripley at stats.ox.ac.uk Tue Nov 11 19:33:26 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 11 Nov 2008 18:33:26 +0000 (GMT) Subject: [Rd] Linking to headers and shared library in another package In-Reply-To: <4919B7D3.8050105@gmail.com> References: <4919B7D3.8050105@gmail.com> Message-ID: Please review the latest version of 'Writing R Extensions'. What is documented there has been tested with packages in different libraries, including none in $(R_HOME)/library. Note however that on a Unix-alike linking even to $(R_HOME)/library/firstPkg/libs/firstPkg.so cannot work in general as that location is not in the ld.so search path when R is started and so the .so will not be located. On Tue, 11 Nov 2008, Iago Mosqueira wrote: > Hi, > > A package with some C code needs to use the headers and shared library > in another package during installation/compilation. The first one is > achieved through the LinkingTo option in DESCRIPTION. For the second a > Makevars file with > > PKG_LIBS=$(R_HOME)/library/firstPkg/libs/firstPkg.so > > was being used. Problem this is not portable if the firstPkg package is > not installed in the library folder inside R_HOME but lives somewhere else. > > What is the best way for Makevars or configure to find where a package > lives? Or is there any other way to make sure the linking step finds > where the shared library is located? See the Windows examples in 'Writing R Extensions' (for this can be made to work on Windows). > > Apologies if I missed something in the extensions manual, but my limited > experience with autoconf might have made me not notice it. > > Many thanks, > > > Iago > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From christos.hatzis at nuverabio.com Tue Nov 11 19:47:03 2008 From: christos.hatzis at nuverabio.com (Christos Hatzis) Date: Tue, 11 Nov 2008 13:47:03 -0500 Subject: [Rd] is.matrix In-Reply-To: <4919CF75.3010202@biostat.ku.dk> References: <4919CF75.3010202@biostat.ku.dk> Message-ID: And the other missing piece is that t() coerces the input vector to a 1-column matrix that can then be transposed and returned as a 1-row matrix (with a dim attribute). -Christos > -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Peter Dalgaard > Sent: Tuesday, November 11, 2008 1:31 PM > To: Daniel H?yer Iversen > Cc: r-devel at r-project.org > Subject: Re: [Rd] is.matrix > > Daniel H?yer Iversen wrote: > > a=c(1,1,2); > > is.matrix(a) gives FALSE > > is.matrix(t(a)) gives TRUE > > is.matrix(t(t(a))) gives TRUE > > > > Is this correct? Shouldn't all give FALSE? > > I think is.matrix should give FALSE when dimension is 1*n or n*1. > > No this is correct. is.matrix() returns TRUE if and only if > the argument has a two-dimensional 'dim' attribute, and > > > dim(a) > NULL > > dim(t(a)) > [1] 1 3 > > dim(t(t(a))) > [1] 3 1 > > (And is.array() depends on having a 'dim' attribute of > positive length, so > > > dim(a) <- 3 > > is.matrix(a) > [1] FALSE > > is.array(a) > [1] TRUE > > ) > > > -- > O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: > (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: > (+45) 35327907 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From tplate at acm.org Tue Nov 11 19:43:12 2008 From: tplate at acm.org (Tony Plate) Date: Tue, 11 Nov 2008 11:43:12 -0700 Subject: [Rd] is.matrix In-Reply-To: References: Message-ID: <4919D240.4040904@acm.org> Daniel H?yer Iversen wrote: > a=c(1,1,2); > is.matrix(a) gives FALSE > is.matrix(t(a)) gives TRUE > is.matrix(t(t(a))) gives TRUE > > Is this correct? Shouldn't all give FALSE? > I think is.matrix should give FALSE when dimension is 1*n or n*1. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > All of the above is consistent with the documentation for is.matrix(): | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | attribute of length 2) and |FALSE| otherwise [There seems to be a typo in this sentence from ?is.matrix : an unmatched ")"] This is also useful behavior -- when programming it is often useful to know whether something is a matrix or not because that can affect computations performed with the object. For the more informal definition of "matrix" that it looks like want, you could use is.matrix(x) && all(dim(x)>1) (or maybe all(dim(x) != 1) depending on how you want to treat matrices that have a dimension with zero extent) -- Tony Plate From h.wickham at gmail.com Tue Nov 11 20:21:29 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 11 Nov 2008 13:21:29 -0600 Subject: [Rd] is.matrix In-Reply-To: <4919D240.4040904@acm.org> References: <4919D240.4040904@acm.org> Message-ID: > | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | > attribute of length 2) and |FALSE| otherwise That's confusing! In what situations is x a matrix but does not have a dim attribute? Hadley -- http://had.co.nz/ From p.dalgaard at biostat.ku.dk Tue Nov 11 20:33:27 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Tue, 11 Nov 2008 20:33:27 +0100 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: <4919DE07.40106@biostat.ku.dk> hadley wickham wrote: >> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >> attribute of length 2) and |FALSE| otherwise > > That's confusing! In what situations is x a matrix but does not have > a dim attribute? > > Hadley > Yes, I suspect a typo there. -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From danielho at stud.ntnu.no Tue Nov 11 20:35:48 2008 From: danielho at stud.ntnu.no (=?ISO-8859-1?Q?Daniel_H=F8yer_Iversen?=) Date: Tue, 11 Nov 2008 20:35:48 +0100 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: > That's confusing! In what situations is x a matrix but does not have > a dim attribute? That was my point. I don't find it logical that is.matrix(a) gives FALSE but is.matrix(t( t(a) )) gives TRUE. I also think it would be more logical that a=c(1,1,2) dim(a) gives 3 1 instead of NULL, Daniel On Tue, Nov 11, 2008 at 8:21 PM, hadley wickham wrote: >> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >> attribute of length 2) and |FALSE| otherwise > > That's confusing! In what situations is x a matrix but does not have > a dim attribute? > > Hadley > > -- > http://had.co.nz/ > > From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Tue Nov 11 20:42:08 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Tue, 11 Nov 2008 20:42:08 +0100 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: <4919E010.8080603@idi.ntnu.no> hadley wickham wrote: >> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >> attribute of length 2) and |FALSE| otherwise >> > > That's confusing! In what situations is x a matrix but does not have > a dim attribute? > > x = matrix(1,1,1) dim(x) = c(1,1,1) is.matrix(x) # no is("matrix", x) # no is(x) # hm... following the last, there would be a situation in which an object is a matrix (per is(...)) and has a dim attribute of length != 2, but is a matrix (per is.matrix(...) and is("matrix", ...), consistently with the docs). (the redundant "vector" in is(x) could probably be removed?) vQ From h.wickham at gmail.com Tue Nov 11 20:46:50 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 11 Nov 2008 13:46:50 -0600 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: On Tue, Nov 11, 2008 at 1:35 PM, Daniel H?yer Iversen wrote: >> That's confusing! In what situations is x a matrix but does not have >> a dim attribute? > > That was my point. I don't find it logical that > is.matrix(a) gives FALSE but > is.matrix(t( t(a) )) gives TRUE. > > I also think it would be more logical that > a=c(1,1,2) > dim(a) gives 3 1 instead of NULL, In R t(t(a)) != a, because a vector is different to a 1d matrix. This is different to mathematical convention - you could argue that it would have been wise to stick with convention, but there are some good reasons for treating vectors differently to 1d matrices, and its too late to change now. Note that the following are all different in R: a <- 1:3 b <- array(1:3, 3) c <- array(1:3, c(3,1)) d <- array(1:3, c(3,1,1)) e <- array(1:3, c(3,1,1,1)) f <- array(1:3, c(3,1,1,1,1)) Hadley -- http://had.co.nz/ From h.wickham at gmail.com Tue Nov 11 20:48:00 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 11 Nov 2008 13:48:00 -0600 Subject: [Rd] is.matrix In-Reply-To: <4919E010.8080603@idi.ntnu.no> References: <4919D240.4040904@acm.org> <4919E010.8080603@idi.ntnu.no> Message-ID: On Tue, Nov 11, 2008 at 1:42 PM, Wacek Kusnierczyk wrote: > hadley wickham wrote: >>> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >>> attribute of length 2) and |FALSE| otherwise >>> >> >> That's confusing! In what situations is x a matrix but does not have >> a dim attribute? >> >> > > x = matrix(1,1,1) > dim(x) = c(1,1,1) I think you meant dim(x) <- c(3, 1) You created a 1 x 1 x 1 array. Hadley -- http://had.co.nz/ From christos.hatzis at nuverabio.com Tue Nov 11 21:01:51 2008 From: christos.hatzis at nuverabio.com (Christos Hatzis) Date: Tue, 11 Nov 2008 15:01:51 -0500 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: The point was that c(1, 1, 2) is not a matrix but a vector, two distinct things in R. > a <- c(1, 1, 2) > class(a) [1] "numeric" > ta <- t(a) > class(ta) [1] "matrix" > class(t(ta)) [1] "matrix" The transpose operation is only defined for matrices, so if you insist to apply it to a vector, it first needs to be coersed to a matrix and then transposed. The result of this operation is a matrix. The result of transposing this matrix will still be a matrix. -Christos > -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Daniel > H?yer Iversen > Sent: Tuesday, November 11, 2008 2:36 PM > To: hadley wickham > Cc: Tony Plate; r-devel at r-project.org > Subject: Re: [Rd] is.matrix > > > That's confusing! In what situations is x a matrix but > does not have > > a dim attribute? > > That was my point. I don't find it logical that > is.matrix(a) gives FALSE but > is.matrix(t( t(a) )) gives TRUE. > > I also think it would be more logical that > a=c(1,1,2) > dim(a) gives 3 1 instead of NULL, > > > > Daniel > > > > On Tue, Nov 11, 2008 at 8:21 PM, hadley wickham > wrote: > >> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim > >> | | > >> attribute of length 2) and |FALSE| otherwise > > > > That's confusing! In what situations is x a matrix but > does not have > > a dim attribute? > > > > Hadley > > > > -- > > http://had.co.nz/ > > > > > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Tue Nov 11 20:55:04 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Tue, 11 Nov 2008 20:55:04 +0100 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> Message-ID: <4919E318.1010105@idi.ntnu.no> Daniel H?yer Iversen wrote: >> That's confusing! In what situations is x a matrix but does not have >> a dim attribute? >> > > That was my point. I don't find it logical that > is.matrix(a) gives FALSE but > is.matrix(t( t(a) )) gives TRUE. > that's a different story, because t() performs an implicit cast from vector to matrix, so you have t(vector) -> matrix t(matrix) -> matrix t(t(vector)) -> matrix interestingly, x = 1:2 dim(x) = 2 adds "matrix" to is(x), but it is still not is.matrix(x) (consistently with the docs). > I also think it would be more logical that > a=c(1,1,2) > dim(a) gives 3 1 instead of NULL, > well, it might give 3 1 1, or 3 1 1 1, or ..., which all could be considered logical. i think dim(x) giving just 3 would be fine. vQ From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Tue Nov 11 20:58:56 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Tue, 11 Nov 2008 20:58:56 +0100 Subject: [Rd] is.matrix In-Reply-To: References: <4919D240.4040904@acm.org> <4919E010.8080603@idi.ntnu.no> Message-ID: <4919E400.9090707@idi.ntnu.no> hadley wickham wrote: > On Tue, Nov 11, 2008 at 1:42 PM, Wacek Kusnierczyk > wrote: > >> hadley wickham wrote: >> >>>> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >>>> attribute of length 2) and |FALSE| otherwise >>>> >>>> >>> That's confusing! In what situations is x a matrix but does not have >>> a dim attribute? >>> >>> >>> >> x = matrix(1,1,1) >> dim(x) = c(1,1,1) >> > > I think you meant > dim(x) <- c(3, 1) > > You created a 1 x 1 x 1 array. > i know, that's precisely what i wanted. this is a simple 3d structure, yet is(x) reveals it is a matrix. that was the point. some further observations: x = as.list(1:2) is(x) # x is a list dim(x) = 2 is.list(x) # sure is(x) # not so sure any more -- a matrix? vQ From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Tue Nov 11 20:59:49 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Tue, 11 Nov 2008 20:59:49 +0100 Subject: [Rd] is.matrix In-Reply-To: <4919E010.8080603@idi.ntnu.no> References: <4919D240.4040904@acm.org> <4919E010.8080603@idi.ntnu.no> Message-ID: <4919E435.90801@idi.ntnu.no> Wacek Kusnierczyk wrote: > hadley wickham wrote: > >>> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >>> attribute of length 2) and |FALSE| otherwise >>> >>> >> That's confusing! In what situations is x a matrix but does not have >> a dim attribute? >> >> >> > > x = matrix(1,1,1) > dim(x) = c(1,1,1) > is.matrix(x) > # no > is("matrix", x) > # no > is(x) > # hm... > > following the last, there would be a situation in which an object is a > matrix (per is(...)) and has a dim attribute of length != 2, but is a > but is *not* > matrix (per is.matrix(...) and is("matrix", ...), consistently with the > docs). > > (the redundant "vector" in is(x) could probably be removed?) > > vQ > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From h.wickham at gmail.com Tue Nov 11 21:03:22 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 11 Nov 2008 14:03:22 -0600 Subject: [Rd] is.matrix In-Reply-To: <4919E400.9090707@idi.ntnu.no> References: <4919D240.4040904@acm.org> <4919E010.8080603@idi.ntnu.no> <4919E400.9090707@idi.ntnu.no> Message-ID: On Tue, Nov 11, 2008 at 1:58 PM, Wacek Kusnierczyk wrote: > hadley wickham wrote: >> On Tue, Nov 11, 2008 at 1:42 PM, Wacek Kusnierczyk >> wrote: >> >>> hadley wickham wrote: >>> >>>>> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim | >>>>> attribute of length 2) and |FALSE| otherwise >>>>> >>>>> >>>> That's confusing! In what situations is x a matrix but does not have >>>> a dim attribute? >>>> >>>> >>>> >>> x = matrix(1,1,1) >>> dim(x) = c(1,1,1) >>> >> >> I think you meant >> dim(x) <- c(3, 1) >> >> You created a 1 x 1 x 1 array. >> > > i know, that's precisely what i wanted. this is a simple 3d structure, > yet is(x) reveals it is a matrix. that was the point. I think the message here is not to use is(). is() is designed for use with S4 objects, and it doesn't always give what you'd expect for primitive objects. This isn't normally a problem because for those objects you use is.matrix(), is.array(), is.vector() etc. Sure, this isn't a particularly wonderful aspect of the language, but there are far more interesting and important things for people to spend their time on, and fixing these behaviours now could potentially break large amounts of existing code, with little benefit. Hadley -- http://had.co.nz/ From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Tue Nov 11 21:40:52 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Tue, 11 Nov 2008 21:40:52 +0100 Subject: [Rd] error during list allocation Message-ID: <4919EDD4.5070009@idi.ntnu.no> platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status major 2 minor 8.0 year 2008 month 10 day 20 svn rev 46754 language R version.string R version 2.8.0 (2008-10-20) when i try to allocate a large list, i get the following error: Error: vector memory exhausted (limit reached?) the process uses over 80% memory, and cannot be stopped from within r (it responds to whatever input with the same message as above); i need to kill the process to release resources. i think it would be practical to have the error reported *and* resources freed when allocation fails. the following should make a reproducible example: x = 1:(10^9) # Error: cannot allocate vector of size 3.7 Gb # no problem otherwise x = as.list(1:(10^8)) # Error: vector memory exhausted (limit reached?) quit() # Error: vector memory exhausted (limit reached?) 1 # Error: vector memory exhausted (limit reached?) vQ From Jerry.Lewis at biogenidec.com Mon Nov 10 06:00:04 2008 From: Jerry.Lewis at biogenidec.com (Jerry.Lewis at biogenidec.com) Date: Mon, 10 Nov 2008 06:00:04 +0100 (CET) Subject: [Rd] erf calculation (PR#13271) Message-ID: <20081110050004.28654282EF48@mail.pubhealth.ku.dk> Full_Name: Jerry W. Lewis Version: 2.8.0 OS: Windows XP Professional Submission from: (NULL) (71.184.139.210) On p.1202 of the Reference manual, calculating erf(x) is given as an example using the code erf <- function(x) 2 * pnorm(x * sqrt(2)) - 1 A numerically better (avoiding cancellation for x near 0) formula is erf <- function(x){ ret <- pgamma(x^2,0.5,1) ret[x<0] <- -ret[x<0] ret } It would also be convenient if erf and erfc functions were provided in R, as they are in S-PLUS. From patrickbolliger at gmx.ch Mon Nov 10 11:50:06 2008 From: patrickbolliger at gmx.ch (patrickbolliger at gmx.ch) Date: Mon, 10 Nov 2008 11:50:06 +0100 (CET) Subject: [Rd] Timeseries - window - extend problem (PR#13272) Message-ID: <20081110105006.8D7C2282C768@mail.pubhealth.ku.dk> Full_Name: Patrick Bolliger Version: R 2.8.0 OS: Windows XP Submission from: (NULL) (165.222.185.132) I cannot understand the behaviour of the following snippet... I guess it has to do with the representation of the floating number .66666 ----------------------------------------------------------------------------------- CODE-SNIPPET: ============= MTH <- 10 window(ts(1:290,start=c(1984,MTH),freq=12),start=c(2008,9),end=c(2008,9),extend=T) MTH <- 9 window(ts(1:290,start=c(1984,MTH),freq=12),start=c(2008,9),end=c(2008,9),extend=T) ------------------ RESULT: ------------------ > MTH <- 10 > window(ts(1:290,start=c(1984,MTH),freq=12),start=c(2008,9),end=c(2008,9),extend=T) Fehler in ts(x, xtsp[1], xtsp[2], xtsp[3]) : 'start' kann nicht nach 'end' sein > MTH <- 9 > window(ts(1:290,start=c(1984,MTH),freq=12),start=c(2008,9),end=c(2008,9),extend=T) Sep 2008 289 > From gpapkov at rice.edu Mon Nov 10 19:35:12 2008 From: gpapkov at rice.edu (gpapkov at rice.edu) Date: Mon, 10 Nov 2008 19:35:12 +0100 (CET) Subject: [Rd] Issue with Mac OSX version of R (PR#13275) Message-ID: <20081110183513.07566282EFF6@mail.pubhealth.ku.dk> Full_Name: Galen papkov Version: 2.8.0 OS: Tiger v.10.4.11 Submission from: (NULL) (129.7.91.106) The Package Installer cannot seem to find the CRAN source. When I try to "Get List", I get the following error: Error in read.dcf(file = tmpf) : Found continuation line starting ' References: <4919D240.4040904@acm.org><4919E010.8080603@idi.ntnu.no><4919E400.9090707@idi.ntnu.no> Message-ID: <77EB52C6DD32BA4D87471DCD70C8D70028D7F6@NA-PA-VBE03.na.tibco.com> S+, now and as far back as 3.4 (1996) and S versions 3 (c. 1990) and 4 (1999) define is.matrix as function(x)length(dim(x)) == 2 so is.matrix(data.frame(x=1:3,y=4:6)) returns TRUE. It essentially means that you can use 2 subscripts on the object (it assumes that the dim() method for class(x) is defined appropriately). We never changed it to look at the S4 class or the dim attribute directly because that broke old code. Why do people call is.matrix(x)? Bill Dunlap TIBCO Spotfire Inc wdunlap tibco.com > -----Original Message----- > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of hadley wickham > Sent: Tuesday, November 11, 2008 12:03 PM > To: Wacek Kusnierczyk > Cc: r-devel at r-project.org > Subject: Re: [Rd] is.matrix > > On Tue, Nov 11, 2008 at 1:58 PM, Wacek Kusnierczyk > wrote: > > hadley wickham wrote: > >> On Tue, Nov 11, 2008 at 1:42 PM, Wacek Kusnierczyk > >> wrote: > >> > >>> hadley wickham wrote: > >>> > >>>>> | is.matrix| returns |TRUE| if |x| is a matrix and has a |dim > >>>>> | | > >>>>> attribute of length 2) and |FALSE| otherwise > >>>>> > >>>>> > >>>> That's confusing! In what situations is x a matrix but does not > >>>> have a dim attribute? > >>>> > >>>> > >>>> > >>> x = matrix(1,1,1) > >>> dim(x) = c(1,1,1) > >>> > >> > >> I think you meant > >> dim(x) <- c(3, 1) > >> > >> You created a 1 x 1 x 1 array. > >> > > > > i know, that's precisely what i wanted. this is a simple 3d > > structure, yet is(x) reveals it is a matrix. that was the point. > > I think the message here is not to use is(). is() is > designed for use with S4 objects, and it doesn't always give > what you'd expect for primitive objects. This isn't normally > a problem because for those objects you use is.matrix(), > is.array(), is.vector() etc. Sure, this isn't a particularly > wonderful aspect of the language, but there are far more > interesting and important things for people to spend their > time on, and fixing these behaviours now could potentially > break large amounts of existing code, with little benefit. > > Hadley > > > -- > http://had.co.nz/ > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From simon.urbanek at r-project.org Tue Nov 11 23:38:11 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Tue, 11 Nov 2008 17:38:11 -0500 Subject: [Rd] Issue with Mac OSX version of R (PR#13275) In-Reply-To: <20081110183513.07566282EFF6@mail.pubhealth.ku.dk> References: <20081110183513.07566282EFF6@mail.pubhealth.ku.dk> Message-ID: <7E386B5B-58B2-47CD-81FB-C264C8675BB3@r-project.org> Please do your homework before posing invalid bug reports -- apparently the mirror you're using is not currently working - so just pick another one. Also "Other Directory URL" is NOT for repositories as the name implies (ever wondered why there is a "Other Repository" entry?). Thanks, S On Nov 10, 2008, at 13:35 , gpapkov at rice.edu wrote: > Full_Name: Galen papkov > Version: 2.8.0 > OS: Tiger v.10.4.11 > Submission from: (NULL) (129.7.91.106) > > > The Package Installer cannot seem to find the CRAN source. When I > try to "Get > List", I get the following error: > > Error in read.dcf(file = tmpf) : > Found continuation line starting ' begin of > record. > > I also tried to put the URL in directly with the "Other Directory > URL" option > and I got > > Warning: unable to access index for repository http://cran.r-project.org/ > > Thank you. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From ifrades at cicbiogune.es Wed Nov 12 17:28:36 2008 From: ifrades at cicbiogune.es (Itziar Frades Alzueta) Date: Wed, 12 Nov 2008 17:28:36 +0100 Subject: [Rd] what does negative indexing in a matrix mean? Message-ID: <8D38CA497C4E964497B80E175EEB9081012836@MAILBOXES.cicbiogune.int> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From simon.urbanek at r-project.org Wed Nov 12 17:42:36 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Wed, 12 Nov 2008 11:42:36 -0500 Subject: [Rd] what does negative indexing in a matrix mean? In-Reply-To: <8D38CA497C4E964497B80E175EEB9081012836@MAILBOXES.cicbiogune.int> References: <8D38CA497C4E964497B80E175EEB9081012836@MAILBOXES.cicbiogune.int> Message-ID: On Nov 12, 2008, at 11:28 , Itziar Frades Alzueta wrote: > Hi, > > Does anyone know what the negative indexing of a matrix mean? > > ?`[` For '['-indexing only: 'i, j, ...' can be logical vectors, indicating elements/slices to select. Such vectors are recycled if necessary to match the corresponding extent. 'i, j, ...' can also be negative integers, indicating elements/slices to leave out of the selection. .. so in your case you're removing one of the predictors (and I don't think you really have a matrix there ...). Cheers, S > > I am using the RWeka and this evaluate classifier does not work on new > data like this > > > > e <- evaluate_Weka_classifier(m1235,newdata=XW4, complexity = > FALSE,class = FALSE) > > > > while it work with negative indexing: > > > > e <- evaluate_Weka_classifier(m1235,newdata=XW4[,-2], complexity = > FALSE,class = FALSE) > > > > Although I do not understand what negative indexing of a matrix means, > or whether it produces any transformation. > > > > Regards, > > > > Itziar Frades > > > > > > > > This e-mail is from CIC bioGUNE. The e-mail and any files > transmitted with it are confidential and intended solely for the use > of the individual or entity to whom they are addressed. Any > unauthorised dissemination or copying of this e-mail or its > attachments, and any use or disclosure of any information contained > in them, is strictly prohibited and may be illegal. If you have > received this e-mail in error, please notify or telephone + 34 944 > 06 13 00 and delete it from your system. > > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From wdunlap at tibco.com Wed Nov 12 19:50:13 2008 From: wdunlap at tibco.com (William Dunlap) Date: Wed, 12 Nov 2008 10:50:13 -0800 Subject: [Rd] Splus-specific entries in pkg/DESCRIPTION files Message-ID: <77EB52C6DD32BA4D87471DCD70C8D70028DA72@NA-PA-VBE03.na.tibco.com> In the past few years we have been working on making it possible to use packages in both R and Spotfire S+ (previously officially called S-PLUS). One problem was that certain lines in the DESCRIPTION file of a package needed to be specific to R or Spotfire S+. E.g., if your package used the xyplot() function then the package would depend upon lattice in R and trellis in Spotfire S+, or a package might require R 2.8.0 or S+ 8.1 to work properly. Another example might be that R's build system requires that the Maintainer: line contains an e-mail address but in Spotfire S+ a URL is acceptable. Our solution to this is that if a DESCRIPTION file has entries tagged 'Xyx:' and 'XyzSplus:' then S+'s read.dcf() function will ignore the 'Xyz:' entry and output the 'XyzSplus:' entry as the 'Xyz:' entry. E.g., the Depends: example above would be handled by putting the following 2 lines in DESCRIPTION Depends: R (>= 2.8.0), lattice DependsSplus: Splus (>= 8.1), trellis When R's read.dcf() reads that DESCRIPTION file the Depends component of its output would be "R (>= 2.8.0), lattice" and when S+'s read.dcf() reads it the Depends component would be "Splus (>= 8.1), trellis". R's read.dcf() would also return the component "DependsSplus", but that should not hurt anything as long as the Depends component were also present (otherwise partial matching could cause x$Depends to give you x$DependsSplus). The Maintainer: issue would be handled by Maintainer: Joe the Package Writer MaintainerSplus: Acme Support S+'s read.dcf() has an argument, convertSplusLines=TRUE, that one can use to avoid this translation (useful mainly when copying DESCRIPTION files by using write.dcf(read.dcf(oldfile),newfile)). This should not affect how things work in R (unless a package writer had a tag ending with 'Splus') but package writers may find it handy or may wonder why we add such lines when we help port their packages to Spotfire S+. This feature is new to Spotfire S+ 8.1. Bill Dunlap TIBCO Spotfire Inc wdunlap tibco.com From lhansen at blackmesacapital.com Thu Nov 13 04:35:03 2008 From: lhansen at blackmesacapital.com (lhansen at blackmesacapital.com) Date: Thu, 13 Nov 2008 04:35:03 +0100 (CET) Subject: [Rd] Package install problem on Windows (PR#13284) Message-ID: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> Full_Name: Lars Hansen Version: 2.8.0 OS: Windows XP Pro x64 SP2 Submission from: (NULL) (71.39.177.36) Hi, I have run into a problem using "R CMD INSTALL" with the "--with-package-versions" option under Windows. It is a bit obscure, which could explain why other people have not run into it. We happen to have two packages with almost the same name. One name is a subset of the other. The names are "RtTests" and "RtTestsEG1". I have no problem installing "RtTests" and many other packages, but run into problems installing "RtTestsEG1". The "RtTestsEG1" package happens to be a simple example of how to use the "RtTests" package, so it depends on "RtTests" (which is probably the problem). OK, so this is what happens when I attempt to install "RtTestsEG1": $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 installing RtTestsEG1 package ---------- Making package RtTestsEG1 ------------ adding build stamp to DESCRIPTION installing R files preparing package RtTestsEG1 for lazy loading Loading required package: RtTests ... [lost of lines removed] Loading required package: RtTests Error: evaluation nested too deeply: infinite recursion / options(expressions=)? Execution halted make[2]: *** [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** [pkg-RtTestsEG1] Error 2 *** Installation of RtTestsEG1 failed *** After some digging in the Windows makefiles, I found out that changing the locale from "C" to "us" in the "lazyload" target of $R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of "LC_ALL=C", solves the infinite recursion problem and give an useful message. It still fails but now says: Loading required package: RtTests Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults', 'print.RtTestSetResults.summary' were declared in NAMESPACE but not found Error in namespaceExport(ns, exports) : undefined exports: parseTranscriptFile, compareTranscriptAndOutput Error: package 'RtTests' could not be loaded Execution halted It is true that RtTests declares the various functions in its name space, but why can they suddenly not be found? If I load RtTests by itself, i.e. library(RtTests), there is no problem. I happen to have all this working under Linux, so I tracked down the difference. Turns out that under Linux the equivalent to the "lazyload" target is in "/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to "tools:::makeLazyLoading". Under Linux the full package name with version number is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests". So I managed to fix the problem by making Windows use the full package name in the "lazyload" target. I replaced tools:::makeLazyLoading(\"$(PKG)\" with tools:::makeLazyLoading(\"$(notdir $(DPKG))\" If I now reinstall "RtTests", I can finally install "RtTestsEG1". I must confess, that I do not fully understand exactly what it takes to reproduce this problem. I am guessing that all it takes is a package depending on a versioned package. Maybe the similarity in names introduces a problem because of partial matching. I am guessing that has nothing to do with it. To sum up the report. I see two problems: 1) LC_ALL=C causes infinite recursion. It is as if the C locale does not work under Windows. I do not know what the fix is. It is used many places in install scripts and makefiles. Fixing it in the "lazyload" target is not enough. Even with my change I still get "infinite recursion" and no error message if I try to install "RtTestsEG1" without first installing "RtTests". 2) "makeLazyLoading()" in "lazyload" target needs to be called with full package name with embedded version number. I think this is bug under Windows and my fix takes care of it. It took some time to figure this out. I am hoping this report will save other people time. I am note sure if I succeeded in describing the problem clearly. Please do not hesitate to ask for clarification. Thanks, Lars Hansen P.S. > sessionInfo() R version 2.8.0 Patched (2008-10-22 r46776) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MONETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base From jeff.a.ryan at gmail.com Thu Nov 13 05:16:56 2008 From: jeff.a.ryan at gmail.com (Jeff Ryan) Date: Wed, 12 Nov 2008 22:16:56 -0600 Subject: [Rd] Dynamic linking to binary code from other packages?? In-Reply-To: <8adccabf0811101153w6a9e93bfvd7a24138f3c6b15b@mail.gmail.com> References: <8adccabf0810251305o3ad8483x5de5009605fbdbe1@mail.gmail.com> <18691.32336.501605.415161@ron.nulle.part> <8adccabf0811101153w6a9e93bfvd7a24138f3c6b15b@mail.gmail.com> Message-ID: Charles, > I've looked through the "Writing R Extensions" manual, and can't find > this documented very clearly. A previous question to the list gave me > the very kind response pasted below. I've looked at the suggested > examples (lme4 using C functions from Matrix). It isn't really "clearly" explained. I will give it a try though. You can't use compiled/packaged functions from within _your_ compiled code unless the package that you are referring to (affxparser) makes them available for export. If affxparser doesn't do this you are back to Dirk's method. For the sake of others who have gone down this road I will explain what I know, and probably in the process learn what I may be doing wrong. (all of this I learned by reading the sources for R and lme4 and Matrix). Matrix has a copy of the Matrix.h header in its /inst directory, specifically /inst/include/Matrix.h This gets installed as /include/Matrix.h, which is where LinkingTo links to during compilation. You (or the affxparser author) will also need a handful of C calls that are complementary to ones in the package you are getting the functions from. An example from Matrix: /include/Matrix_stubs.c contains ... CHM_DN attribute_hidden M_as_cholmod_dense(CHM_DN ans, SEXP x) { static CHM_DN(*fun)(CHM_DN,SEXP) = NULL; if(fun == NULL) fun = (CHM_DN(*)(CHM_DN,SEXP)) R_GetCCallable("Matrix", "as_cholmod_dense"); return fun(ans, x); } ... The above is far from obvious, so I will try my best to explain. With respect to the R_GetCCallable call, Writing R Extensions says: " p_myCfun = R_GetCCallable("packA", "myCfun"); The author of packB is responsible for ensuring that p_myCfun has an appropriate declaration. What exactly that means was hard to determine at first." Taking the first line, the first CHM_DN is the function return type (could be int, SEXP, etc), and the second (along with the SEXP) is the argument type(s). Generalized you'd have something like: SEXP attribute_hidden FUNNAME(SEXP ans, SEXP x) { static SEXP(*fun)(SEXP,SEXP) = NULL; if(fun == NULL) fun = (SEXP(*)(SEXP,SEXP)) R_GetCCallable("PACKAGE", "FUNCTION"); return fun(ans, x); } lme4 then simply "#include"s this .c file in a file /src/local_stubs.c, which is compiled right along side of the src code in lme4. At this point you can then use the functions that are 'exported/registered' as you would a C function defined in your own package. The other side of this is what the Matrix (affxparser?) package needs to do. It needs a registration routine that specifically registers the routines as callable using: R_RegisterCCallable (which is documented in Writing R Extensions) In Matrix this is in /src/init.c via a macro. A simpler in-progress bit of code can be found in the /dev branch of xts on R-forge. Take a look at http://r-forge.r-project.org/scm/?group_id=118 /dev/src/init.c /dev/inst/include/xts.h /dev/inst/include/xts_stubs.c As far as C++ goes, I would suspect the Matrix package again has all the bits you are looking for. HTH Jeff -- Jeffrey Ryan jeffrey.ryan at insightalgo.com ia: insight algorithmics www.insightalgo.com From ripley at stats.ox.ac.uk Thu Nov 13 07:42:15 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Thu, 13 Nov 2008 06:42:15 +0000 (GMT) Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> Message-ID: Installing versioned packages is not supported with namespaces. I have suggested from time to time that versioned installs be removed because of this and other known issues, and recommend that you do not attempt to use them. On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: > Full_Name: Lars Hansen > Version: 2.8.0 > OS: Windows XP Pro x64 SP2 > Submission from: (NULL) (71.39.177.36) > > > Hi, > > I have run into a problem using "R CMD INSTALL" with the > "--with-package-versions" option under Windows. It is a bit obscure, which could > explain why other people have not run into it. > > We happen to have two packages with almost the same name. One name is a subset > of the other. The names are "RtTests" and "RtTestsEG1". I have no problem > installing "RtTests" and many other packages, but run into problems installing > "RtTestsEG1". The "RtTestsEG1" package happens to be a simple example of how to > use the "RtTests" package, so it depends on "RtTests" (which is probably the > problem). > > OK, so this is what happens when I attempt to install "RtTestsEG1": > > $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 > > installing RtTestsEG1 package > > ---------- Making package RtTestsEG1 ------------ > adding build stamp to DESCRIPTION > installing R files > preparing package RtTestsEG1 for lazy loading > Loading required package: RtTests > ... [lost of lines removed] > Loading required package: RtTests > Error: evaluation nested too deeply: infinite recursion / > options(expressions=)? > Execution halted > make[2]: *** [lazyload] Error 1 > make[1]: *** [all] Error 2 > make: *** [pkg-RtTestsEG1] Error 2 > *** Installation of RtTestsEG1 failed *** > > After some digging in the Windows makefiles, I found out that changing the > locale from "C" to "us" in the "lazyload" target of > $R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of "LC_ALL=C", > solves the infinite recursion problem and give an useful message. It still fails > but now says: > > Loading required package: RtTests > Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults', > 'print.RtTestSetResults.summary' were declared in NAMESPACE but not found > Error in namespaceExport(ns, exports) : > undefined exports: parseTranscriptFile, compareTranscriptAndOutput > Error: package 'RtTests' could not be loaded > Execution halted > > It is true that RtTests declares the various functions in its name space, but > why can they suddenly not be found? If I load RtTests by itself, i.e. > library(RtTests), there is no problem. > > I happen to have all this working under Linux, so I tracked down the difference. > Turns out that under Linux the equivalent to the "lazyload" target is in > "/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to > "tools:::makeLazyLoading". Under Linux the full package name with version number > is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests". > > So I managed to fix the problem by making Windows use the full package name in > the "lazyload" target. I replaced > tools:::makeLazyLoading(\"$(PKG)\" > with > tools:::makeLazyLoading(\"$(notdir $(DPKG))\" > > If I now reinstall "RtTests", I can finally install "RtTestsEG1". > > I must confess, that I do not fully understand exactly what it takes to > reproduce this problem. I am guessing that all it takes is a package depending > on a versioned package. Maybe the similarity in names introduces a problem > because of partial matching. I am guessing that has nothing to do with it. > > To sum up the report. I see two problems: > > 1) LC_ALL=C causes infinite recursion. It is as if the C locale does not work > under Windows. I do not know what the fix is. It is used many places in install > scripts and makefiles. Fixing it in the "lazyload" target is not enough. Even > with my change I still get "infinite recursion" and no error message if I try to > install "RtTestsEG1" without first installing "RtTests". > > 2) "makeLazyLoading()" in "lazyload" target needs to be called with full package > name with embedded version number. I think this is bug under Windows and my fix > takes care of it. > > It took some time to figure this out. I am hoping this report will save other > people time. I am note sure if I succeeded in describing the problem clearly. > Please do not hesitate to ask for clarification. > > Thanks, > Lars Hansen > > P.S. >> sessionInfo() > R version 2.8.0 Patched (2008-10-22 r46776) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_United States.1252;LC_CTYPE=English_United > States.1252;LC_MONETARY=English_United > States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From simon.urbanek at r-project.org Thu Nov 13 15:15:59 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Thu, 13 Nov 2008 09:15:59 -0500 Subject: [Rd] Dynamic linking to binary code from other packages?? In-Reply-To: References: <8adccabf0810251305o3ad8483x5de5009605fbdbe1@mail.gmail.com> <18691.32336.501605.415161@ron.nulle.part> <8adccabf0811101153w6a9e93bfvd7a24138f3c6b15b@mail.gmail.com> Message-ID: <37726678-4F42-4AC0-98EC-4481DB69F4AA@r-project.org> On Nov 12, 2008, at 23:16 , Jeff Ryan wrote: > Charles, > >> I've looked through the "Writing R Extensions" manual, and can't find >> this documented very clearly. A previous question to the list gave >> me >> the very kind response pasted below. I've looked at the suggested >> examples (lme4 using C functions from Matrix). > > It isn't really "clearly" explained. I will give it a try though. > > You can't use compiled/packaged functions from within _your_ compiled > code unless the package that you are referring to (affxparser) makes > them available for export. > > If affxparser doesn't do this you are back to Dirk's method. > > For the sake of others who have gone down this road I will explain > what I know, and probably in the process learn what I may be doing > wrong. (all of this I learned by reading the sources for R and lme4 > and Matrix). > > Matrix has a copy of the Matrix.h header in its /inst directory, > specifically /inst/include/Matrix.h > > This gets installed as /include/Matrix.h, which is where LinkingTo > links to during compilation. > > You (or the affxparser author) will also need a handful of C calls > that are complementary to ones in the package you are getting the > functions from. > > An example from Matrix: > > /include/Matrix_stubs.c contains > > ... > CHM_DN attribute_hidden > M_as_cholmod_dense(CHM_DN ans, SEXP x) > { > static CHM_DN(*fun)(CHM_DN,SEXP) = NULL; > if(fun == NULL) > fun = (CHM_DN(*)(CHM_DN,SEXP)) > R_GetCCallable("Matrix", "as_cholmod_dense"); > return fun(ans, x); > } > ... > FWIW this is not exactly the most efficient way to do it. It's much easier to do it the commonly used way of setting the function pointers directly (taking the situation above): CHM_DN(*M_as_cholmod_dense)(CHM_DN,SEXP); in the initialization function of the package populate all the pointers: M_as_cholmod_dense = (CHM_DN(*)(CHM_DN,SEXP)) R_GetCCallable("Matrix", "as_cholmod_dense"); By setting the functions right away you save yourself the trouble of checking it on every call and using a function call twice. This allows you to use the function transparently in your code, so you don' t need any function wrappers: x = M_as_cholmod_dense(a, b); This is pretty much standard C programming, so the above should be quite obvious (I hope). The only reason to do it the complicated way above is if you want to do some extra processing in the wrapper function so your function pointer is not visible from outside the function. Cheers, Simon > The above is far from obvious, so I will try my best to explain. > > With respect to the R_GetCCallable call, Writing R Extensions says: > > " p_myCfun = R_GetCCallable("packA", "myCfun"); > The author of packB is responsible for ensuring that p_myCfun has an > appropriate declaration. What exactly that means was hard to determine > at first." > > Taking the first line, the first CHM_DN is the function return type > (could be int, SEXP, etc), and the second (along with the SEXP) is the > argument type(s). > > Generalized you'd have something like: > > SEXP attribute_hidden > FUNNAME(SEXP ans, SEXP x) > { > static SEXP(*fun)(SEXP,SEXP) = NULL; > if(fun == NULL) > fun = (SEXP(*)(SEXP,SEXP)) > R_GetCCallable("PACKAGE", "FUNCTION"); > return fun(ans, x); > } > > lme4 then simply "#include"s this .c file in a file > /src/local_stubs.c, which is compiled right along side of the src code > in lme4. > > At this point you can then use the functions that are > 'exported/registered' as you would a C function defined in your own > package. > > The other side of this is what the Matrix (affxparser?) package needs > to do. It needs a registration routine that specifically registers > the routines as callable using: > R_RegisterCCallable (which is documented in Writing R Extensions) > > In Matrix this is in /src/init.c via a macro. > > A simpler in-progress bit of code can be found in the /dev branch of > xts on R-forge. Take a look at > > http://r-forge.r-project.org/scm/?group_id=118 > > /dev/src/init.c > /dev/inst/include/xts.h > /dev/inst/include/xts_stubs.c > > As far as C++ goes, I would suspect the Matrix package again has all > the bits you are looking for. > > HTH > Jeff > > > > > -- > Jeffrey Ryan > jeffrey.ryan at insightalgo.com > > ia: insight algorithmics > www.insightalgo.com > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From murdoch at stats.uwo.ca Thu Nov 13 17:02:01 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 11:02:01 -0500 Subject: [Rd] Experimental Rd parser in trunk. Message-ID: <491C4F79.3020004@stats.uwo.ca> I've just committed the parse_Rd() function to R-devel. This is a parser for Rd files, described in http://developer.r-project.org/parseRd.pdf It is not identical to the current parser, and about a dozen of the base man pages currently signal syntax errors. It also detected errors in 10 files that were errors according to both definitions, but were missed by the current system, and I've already fixed those. I plan to patch the rest so that they work in both systems soon. The differences between the two systems are described in the document above. I would like to hear comments about the changes -- some of them are still optional. I will be continuing to work on support functions for the parser, e.g. the print routine is currently quite primitive. I expect there may be incompatibilities with platforms on which I haven't tested. I developed the parser on Windows, and have tested it on a Linux system. There may be problems handling Rd files with unusual encodings (UTF-8 and Latin1 should be supported, but I don't know about others, and haven't even tested those yet). Duncan Murdoch From droberts at montana.edu Thu Nov 13 19:35:51 2008 From: droberts at montana.edu (Dave Roberts) Date: Thu, 13 Nov 2008 11:35:51 -0700 Subject: [Rd] gfortran optimization problems In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D7000FF581@NA-PA-VBE03.na.tibco.com> References: <490251F3.6050301@montana.edu> <77EB52C6DD32BA4D87471DCD70C8D7000FF581@NA-PA-VBE03.na.tibco.com> Message-ID: <491C7387.9050403@montana.edu> Bill and Mike, Thanks for your help. I think Mike was right about the 80-bit/64-bit compare. As Mike thought, the error occurs at a test for equality, i.e. if (x .ge. y) then I know better than to test reals for equality, but this is a closed interval test, and it still fails. if (x-y .gt. -0.00001) worked. Bill, thanks for the tip on --ffloat-store. I tried gfortran -c alt_duleg.f gcc -std=gnu99 -ffloat-store -shared -L/usr/local/lib -o alt_duleg.so alt_duleg.o -lgfortran -lm -lgcc_s (standard R CMD SHLIB except for the addition of --float-store) and it seems to have cleared up the problem. I should have seen this coming, since I once had a comparison fail on a 4-byte real versus a double precision that I know are exactly the same in base10. To fix that I canged EVERYTHING to double precision, but I didn't see the register problem coning at all. Now I need to figure out how to implement a makefile for my package, but that's another story and easily solved I suspect. Thanks to everyone who took a stab at this one. I learned a lot. Sorry to have taken so long to get back to it, but other priorities demanded so. Dave ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email droberts at montana.edu Montana State University Bozeman, MT 59717-3460 William Dunlap wrote: > > >> -----Original Message----- >> From: William Dunlap >> Sent: Monday, November 03, 2008 8:34 AM >> To: 'Mike Prager'; 'droberts at montana.edu' >> Subject: RE: [Rd] gfortran optimization problems > ... >> Another common problem, in C or Fortran, is that optimization >> can result in a very small floating point number remaining in >> an 80-bit floating-point-unit register instead of being >> truncated to the 64-bits available in main memory. The >> difference in roundoff error can result in big differences in >> results if your algorithm is ill conditioned or has a test >> for an exact 0.0. >> Adding a debugging WRITE or printf statement generally causes >> the variable to be copied to 64-bit main memory. > > A quick way to see if using floating point registers or not > affects your results is to add the gcc flag (probably a gfortran > flag as well) '-ffloat-store'. 'man gcc' says: > > The following options control compiler behavior regarding > floating > point arithmetic. These options trade off between speed and > correct- > ness. All must be specifically enabled. > > -ffloat-store > Do not store floating point variables in registers, and > inhibit > other options that might change whether a floating point > value is > taken from a register or memory. > > This option prevents undesirable excess precision on machines > such > as the 68000 where the floating registers (of the 68881) keep > more > precision than a "double" is supposed to have. Similarly for > the > x86 architecture. For most programs, the excess precision > does > only good, but a few programs rely on the precise definition > of > IEEE floating point. Use -ffloat-store for such programs, > after > modifying them to store all pertinent intermediate > computations > into variables. > > Bill Dunlap > TIBCO Spotfire Inc > wdunlap tibco.com > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ David W. Roberts office 406-994-4548 Professor and Head FAX 406-994-3190 Department of Ecology email droberts at montana.edu Montana State University Bozeman, MT 59717-3460 From murdoch at stats.uwo.ca Thu Nov 13 19:44:50 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 13:44:50 -0500 Subject: [Rd] Experimental Rd parser in trunk. In-Reply-To: References: <491C4F79.3020004@stats.uwo.ca> Message-ID: <491C75A2.6040405@stats.uwo.ca> On 11/13/2008 11:51 AM, Simon Urbanek wrote: > Duncan, > > I had a quick look at the parsers differences and I'm worried about > points 1. and 2. (on p.6) -- does that imply that \R{} is illegal and > so is any \foo{} for any macro \foo that doesn't take any arguments? > IMHO that would be fatal (if I understand it correctly), since that > construct is very often used (and I know of no alternatives) in cases > where you are referencing a macro that is followed by something that > is not a space. E.g.: 1\foo{}2 cannot be written as 1\foo2 as per 6. > so if \foo{} is disallowed there is no way to call \foo between 1 and > 2 when you don't want any spaces to be generated). > Maybe I'm just interpreting is incorrectly, so I just wanted to point > out that issue. Thanks for the comment. You are interpreting it correctly, and that is something that probably needs to change. The reasoning behind the current choice is that macros with optional arguments are ambiguous: for example, in R code, {} might be part of the code, not something for the Rd parser. We currently have \eqn and \deqn that have one or two args, but they're not going to occur in R code, so things currently work. (But if you want to see ugly Bison coding, look at how those VERBMACRO2 macros are handled. The Rd format is not easy to parse, being a mix of latex-like stuff, R code, and just about anything else in verbatim sections.) So I'd really strongly prefer to say that \foo *always* requires an arg, rather than let it be optional, if there are circumstances where it needs one. If we say that \foo never takes an arg, we'll need a way to distinguish between the following space being significant or not. One way is to allow {} or some other marker that signals a break without inserting anything, and is only interpreted in Latex-like mode. Another way (that I prefer) is described below. We could relax things a lot, and allow balanced braces as no-ops in Latex-like mode, but that will miss some typos. I fixed typos in 10 files in r46908, and at least one of those was caught this way, in methods/man/Classes.Rd. It would also introduce an ambiguity, because \eqn and \deqn *are* going to occur in Latex-like mode. So \eqn{foo}{}bar could be either the two-arg version or the one-arg version followed by a no-op before the bar. (The default handling in Bison is that it would be the two-op version.) And I think it would be tricky to write the parser so that {} was handled differently in Latex-like mode from the way it's handled in the other modes. (The other modes count braces and echo them out.) There are currently only 5 macros which take no args: \cr, \dots, \ldots, \R, and \tab. I think the issue will only arise with \dots and \ldots. So my preferred decision would be to push this up a level: when the code is interpreted, \dots and \ldots are not followed by a space. To allow for a user who wants a space, we should introduce a 6th no-argument macro, \sp. Then "1\dots 10" will be rendered as "1...10" and "1\dots\sp 10" will be rendered as "1... 10". Duncan Murdoch > > Thanks, > Simon > > > On Nov 13, 2008, at 11:02 , Duncan Murdoch wrote: > >> I've just committed the parse_Rd() function to R-devel. This is a >> parser for Rd files, described in >> >> http://developer.r-project.org/parseRd.pdf >> >> It is not identical to the current parser, and about a dozen of the >> base man pages currently signal syntax errors. It also detected >> errors in 10 files that were errors according to both definitions, >> but were missed by the current system, and I've already fixed >> those. I plan to patch the rest so that they work in both systems >> soon. The differences between the two systems are described in the >> document above. >> >> I would like to hear comments about the changes -- some of them are >> still optional. I will be continuing to work on support functions >> for the parser, e.g. the print routine is currently quite primitive. >> >> I expect there may be incompatibilities with platforms on which I >> haven't tested. I developed the parser on Windows, and have tested >> it on a Linux system. There may be problems handling Rd files with >> unusual encodings (UTF-8 and Latin1 should be supported, but I don't >> know about others, and haven't even tested those yet). >> >> Duncan Murdoch >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> From murdoch at stats.uwo.ca Thu Nov 13 20:41:17 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 14:41:17 -0500 Subject: [Rd] Experimental Rd parser in trunk. In-Reply-To: <491C75A2.6040405@stats.uwo.ca> References: <491C4F79.3020004@stats.uwo.ca> <491C75A2.6040405@stats.uwo.ca> Message-ID: <491C82DD.2080902@stats.uwo.ca> Just one additional comment in line below: On 11/13/2008 1:44 PM, Duncan Murdoch wrote: > On 11/13/2008 11:51 AM, Simon Urbanek wrote: >> Duncan, >> >> I had a quick look at the parsers differences and I'm worried about >> points 1. and 2. (on p.6) -- does that imply that \R{} is illegal and >> so is any \foo{} for any macro \foo that doesn't take any arguments? >> IMHO that would be fatal (if I understand it correctly), since that >> construct is very often used (and I know of no alternatives) in cases >> where you are referencing a macro that is followed by something that >> is not a space. E.g.: 1\foo{}2 cannot be written as 1\foo2 as per 6. >> so if \foo{} is disallowed there is no way to call \foo between 1 and >> 2 when you don't want any spaces to be generated). >> Maybe I'm just interpreting is incorrectly, so I just wanted to point >> out that issue. > > Thanks for the comment. You are interpreting it correctly, and that is > something that probably needs to change. > > The reasoning behind the current choice is that macros with optional > arguments are ambiguous: for example, in R code, {} might be part of > the code, not something for the Rd parser. We currently have \eqn and > \deqn that have one or two args, but they're not going to occur in R > code, so things currently work. (But if you want to see ugly Bison > coding, look at how those VERBMACRO2 macros are handled. The Rd format > is not easy to parse, being a mix of latex-like stuff, R code, and just > about anything else in verbatim sections.) > > So I'd really strongly prefer to say that \foo *always* requires an arg, > rather than let it be optional, if there are circumstances where it > needs one. > > If we say that \foo never takes an arg, we'll need a way to distinguish > between the following space being significant or not. One way is to > allow {} or some other marker that signals a break without inserting > anything, and is only interpreted in Latex-like mode. Another way (that > I prefer) is described below. I should say that allowing {} to immediately follow one of the 5 no-arg macros, and having it gobbled up by the lexer, would be relatively easy to implement. So then the two examples below could be coded as "1\dots{}10" versus "1\dots 10", which is I think what you were asking for. I have a mild preference for adding \sp (I don't like special cases), but not a strong one. Duncan Murdoch > > We could relax things a lot, and allow balanced braces as no-ops in > Latex-like mode, but that will miss some typos. I fixed typos in 10 > files in r46908, and at least one of those was caught this way, in > methods/man/Classes.Rd. It would also introduce an ambiguity, because > \eqn and \deqn *are* going to occur in Latex-like mode. So > > \eqn{foo}{}bar > > could be either the two-arg version or the one-arg version followed by a > no-op before the bar. (The default handling in Bison is that it would > be the two-op version.) And I think it would be tricky to write the > parser so that {} was handled differently in Latex-like mode from the > way it's handled in the other modes. (The other modes count braces and > echo them out.) > > There are currently only 5 macros which take no args: \cr, \dots, > \ldots, \R, and \tab. I think the issue will only arise with \dots and > \ldots. So my preferred decision would be to push this up a level: > when the code is interpreted, \dots and \ldots are not followed by a > space. To allow for a user who wants a space, we should introduce a 6th > no-argument macro, \sp. Then "1\dots 10" will be rendered as "1...10" > and "1\dots\sp 10" will be rendered as "1... 10". > > Duncan Murdoch > >> >> Thanks, >> Simon >> >> >> On Nov 13, 2008, at 11:02 , Duncan Murdoch wrote: >> >>> I've just committed the parse_Rd() function to R-devel. This is a >>> parser for Rd files, described in >>> >>> http://developer.r-project.org/parseRd.pdf >>> >>> It is not identical to the current parser, and about a dozen of the >>> base man pages currently signal syntax errors. It also detected >>> errors in 10 files that were errors according to both definitions, >>> but were missed by the current system, and I've already fixed >>> those. I plan to patch the rest so that they work in both systems >>> soon. The differences between the two systems are described in the >>> document above. >>> >>> I would like to hear comments about the changes -- some of them are >>> still optional. I will be continuing to work on support functions >>> for the parser, e.g. the print routine is currently quite primitive. >>> >>> I expect there may be incompatibilities with platforms on which I >>> haven't tested. I developed the parser on Windows, and have tested >>> it on a Linux system. There may be problems handling Rd files with >>> unusual encodings (UTF-8 and Latin1 should be supported, but I don't >>> know about others, and haven't even tested those yet). >>> >>> Duncan Murdoch >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >>> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From dankoc at gmail.com Thu Nov 13 20:42:53 2008 From: dankoc at gmail.com (Charles Danko) Date: Thu, 13 Nov 2008 14:42:53 -0500 Subject: [Rd] Dynamic linking to binary code from other packages?? In-Reply-To: <37726678-4F42-4AC0-98EC-4481DB69F4AA@r-project.org> References: <8adccabf0810251305o3ad8483x5de5009605fbdbe1@mail.gmail.com> <18691.32336.501605.415161@ron.nulle.part> <8adccabf0811101153w6a9e93bfvd7a24138f3c6b15b@mail.gmail.com> <37726678-4F42-4AC0-98EC-4481DB69F4AA@r-project.org> Message-ID: <8adccabf0811131142m341d95datdc275f2619d1133e@mail.gmail.com> Dear list, Thanks very much for all of the detailed responses! I am beginning to understand how all of this can work, and learning quite a bit about the C language in the process! Can this be applied to either C++ classes or to member functions of a class? Please forgive my lack of general C/C++ knowledge, which may be abundantly clear in my specific questions: It seems pretty clear that one may not register a pointer to a class declaration and share it in this way?! Will it work to register a pointer to a class' member functions, using the code described by either Jeff or Simon? I looked into this, and am pretty sure that it can not work. (Here is a good article on registering a pointer to a class' member function: http://www.goingware.com/tips/member-pointers.html). So, is there any way to share either C++ classes or class member functions with another package in R? Again, please do forgive my inexperience. Best, Charles On Thu, Nov 13, 2008 at 9:15 AM, Simon Urbanek wrote: > On Nov 12, 2008, at 23:16 , Jeff Ryan wrote: > >> Charles, >> >>> I've looked through the "Writing R Extensions" manual, and can't find >>> this documented very clearly. A previous question to the list gave me >>> the very kind response pasted below. I've looked at the suggested >>> examples (lme4 using C functions from Matrix). >> >> It isn't really "clearly" explained. I will give it a try though. >> >> You can't use compiled/packaged functions from within _your_ compiled >> code unless the package that you are referring to (affxparser) makes >> them available for export. >> >> If affxparser doesn't do this you are back to Dirk's method. >> >> For the sake of others who have gone down this road I will explain >> what I know, and probably in the process learn what I may be doing >> wrong. (all of this I learned by reading the sources for R and lme4 >> and Matrix). >> >> Matrix has a copy of the Matrix.h header in its /inst directory, >> specifically /inst/include/Matrix.h >> >> This gets installed as /include/Matrix.h, which is where LinkingTo >> links to during compilation. >> >> You (or the affxparser author) will also need a handful of C calls >> that are complementary to ones in the package you are getting the >> functions from. >> >> An example from Matrix: >> >> /include/Matrix_stubs.c contains >> >> ... >> CHM_DN attribute_hidden >> M_as_cholmod_dense(CHM_DN ans, SEXP x) >> { >> static CHM_DN(*fun)(CHM_DN,SEXP) = NULL; >> if(fun == NULL) >> fun = (CHM_DN(*)(CHM_DN,SEXP)) >> R_GetCCallable("Matrix", "as_cholmod_dense"); >> return fun(ans, x); >> } >> ... >> > > FWIW this is not exactly the most efficient way to do it. It's much easier > to do it the commonly used way of setting the function pointers directly > (taking the situation above): > > CHM_DN(*M_as_cholmod_dense)(CHM_DN,SEXP); > > in the initialization function of the package populate all the pointers: > > M_as_cholmod_dense = (CHM_DN(*)(CHM_DN,SEXP)) R_GetCCallable("Matrix", > "as_cholmod_dense"); > > By setting the functions right away you save yourself the trouble of > checking it on every call and using a function call twice. This allows you > to use the function transparently in your code, so you don' t need any > function wrappers: > > x = M_as_cholmod_dense(a, b); > > This is pretty much standard C programming, so the above should be quite > obvious (I hope). > > The only reason to do it the complicated way above is if you want to do some > extra processing in the wrapper function so your function pointer is not > visible from outside the function. > > Cheers, > Simon > > >> The above is far from obvious, so I will try my best to explain. >> >> With respect to the R_GetCCallable call, Writing R Extensions says: >> >> " p_myCfun = R_GetCCallable("packA", "myCfun"); >> The author of packB is responsible for ensuring that p_myCfun has an >> appropriate declaration. What exactly that means was hard to determine >> at first." >> >> Taking the first line, the first CHM_DN is the function return type >> (could be int, SEXP, etc), and the second (along with the SEXP) is the >> argument type(s). >> >> Generalized you'd have something like: >> >> SEXP attribute_hidden >> FUNNAME(SEXP ans, SEXP x) >> { >> static SEXP(*fun)(SEXP,SEXP) = NULL; >> if(fun == NULL) >> fun = (SEXP(*)(SEXP,SEXP)) >> R_GetCCallable("PACKAGE", "FUNCTION"); >> return fun(ans, x); >> } >> >> lme4 then simply "#include"s this .c file in a file >> /src/local_stubs.c, which is compiled right along side of the src code >> in lme4. >> >> At this point you can then use the functions that are >> 'exported/registered' as you would a C function defined in your own >> package. >> >> The other side of this is what the Matrix (affxparser?) package needs >> to do. It needs a registration routine that specifically registers >> the routines as callable using: >> R_RegisterCCallable (which is documented in Writing R Extensions) >> >> In Matrix this is in /src/init.c via a macro. >> >> A simpler in-progress bit of code can be found in the /dev branch of >> xts on R-forge. Take a look at >> >> http://r-forge.r-project.org/scm/?group_id=118 >> >> /dev/src/init.c >> /dev/inst/include/xts.h >> /dev/inst/include/xts_stubs.c >> >> As far as C++ goes, I would suspect the Matrix package again has all >> the bits you are looking for. >> >> HTH >> Jeff >> >> >> >> >> -- >> Jeffrey Ryan >> jeffrey.ryan at insightalgo.com >> >> ia: insight algorithmics >> www.insightalgo.com >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > From murdoch at stats.uwo.ca Thu Nov 13 22:14:33 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 16:14:33 -0500 Subject: [Rd] Experimental Rd parser in trunk. In-Reply-To: <491C82DD.2080902@stats.uwo.ca> References: <491C4F79.3020004@stats.uwo.ca> <491C75A2.6040405@stats.uwo.ca> <491C82DD.2080902@stats.uwo.ca> Message-ID: <491C98B9.3000205@stats.uwo.ca> A couple more comments on the \dots problem: 1. Allowing {} after \dots is unsatisfactory, because the current parser will render the braces, i.e. 1\dots{}10 is rendered as 1..{}10. I'd like to have enough back-compatibility that it is possible to rewrite a man page to work in either system. 2. I could change the rules for what ends a markup macro, to allow only alphabetic chars in one, so that 1\dots10 is legal again. This would require changing or making exceptions for \linkS4class, \S3method, and \S4method, because they contain digits. I think this would rule out ever creating macros \linkS or \S because of the ambiguity; the latter might be a worry. So I'm still leaning towards adding \sp... Duncan Murdoch From pdunn2 at usc.edu.au Thu Nov 13 00:05:08 2008 From: pdunn2 at usc.edu.au (pdunn2 at usc.edu.au) Date: Thu, 13 Nov 2008 00:05:08 +0100 (CET) Subject: [Rd] Documentation error in Writing R Extensions (PR#13282) Message-ID: <20081112230508.74FB2282EFC1@mail.pubhealth.ku.dk> Full_Name: Peter K Dunn Version: NA OS: NA Submission from: (NULL) (203.29.106.59) Reading the manual "Writing R Extensions", the html and pdf versions both contain important typos in Section 1.10. As an example: An installed file named ?CTIATION? will be used by the citation() function. .. The word CTIATION presumably should be CITATION. This occurs four times in Section 1.10, even though the section is called CITATION files. P. From ocheyett at bonddesk.com Thu Nov 13 02:30:06 2008 From: ocheyett at bonddesk.com (ocheyett at bonddesk.com) Date: Thu, 13 Nov 2008 02:30:06 +0100 (CET) Subject: [Rd] R crashes on sprintf with bad format specification (PR#13283) Message-ID: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk> Full_Name: Oren Cheyette Version: 2.7.2 OS: Win XP Submission from: (NULL) (64.161.123.194) Enter the following at the R command prompt: > sprintf("A %S %S %S XYZ", 1, 1, 1); Note the erroneous capitalized %S instead of %s and the numeric inputs instead of strings. With strings there's no crash - R reports bad format specifications. From tplate at acm.org Fri Nov 14 00:11:27 2008 From: tplate at acm.org (Tony Plate) Date: Thu, 13 Nov 2008 16:11:27 -0700 Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> Message-ID: <491CB41F.503@acm.org> Thanks for the response. Are the problems with versioned installs fundamental, or are they just a case of incomplete implementation and rough edges? If the latter, would fixes be considered? I ask because we would find versioned installs very useful in maintaining stable production systems, each of which might run with different versions of various packages, while making it easy to continually develop and refine our packages. As a point of info, our primary use for versioning would be with our own packages, so we could probably get away without using versioned installs for base or contributed packages. However, if the problems with versioned installs are not amenable to the kinds of fixes that users can contribute, then I guess we should look for a different approach. Suggestions and comments are welcome! Do many people use versioned installs? -- Tony Plate (coworker of Lars @ blackmesacapital.com) Prof Brian Ripley wrote: > Installing versioned packages is not supported with namespaces. I > have suggested from time to time that versioned installs be removed > because of this and other known issues, and recommend that you do not > attempt to use them. > > On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: > >> Full_Name: Lars Hansen >> Version: 2.8.0 >> OS: Windows XP Pro x64 SP2 >> Submission from: (NULL) (71.39.177.36) >> >> >> Hi, >> >> I have run into a problem using "R CMD INSTALL" with the >> "--with-package-versions" option under Windows. It is a bit obscure, >> which could >> explain why other people have not run into it. >> >> We happen to have two packages with almost the same name. One name is >> a subset >> of the other. The names are "RtTests" and "RtTestsEG1". I have no >> problem >> installing "RtTests" and many other packages, but run into problems >> installing >> "RtTestsEG1". The "RtTestsEG1" package happens to be a simple example >> of how to >> use the "RtTests" package, so it depends on "RtTests" (which is >> probably the >> problem). >> >> OK, so this is what happens when I attempt to install "RtTestsEG1": >> >> $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 >> >> installing RtTestsEG1 package >> >> ---------- Making package RtTestsEG1 ------------ >> adding build stamp to DESCRIPTION >> installing R files >> preparing package RtTestsEG1 for lazy loading >> Loading required package: RtTests >> ... [lost of lines removed] >> Loading required package: RtTests >> Error: evaluation nested too deeply: infinite recursion / >> options(expressions=)? >> Execution halted >> make[2]: *** [lazyload] Error 1 >> make[1]: *** [all] Error 2 >> make: *** [pkg-RtTestsEG1] Error 2 >> *** Installation of RtTestsEG1 failed *** >> >> After some digging in the Windows makefiles, I found out that >> changing the >> locale from "C" to "us" in the "lazyload" target of >> $R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of >> "LC_ALL=C", >> solves the infinite recursion problem and give an useful message. It >> still fails >> but now says: >> >> Loading required package: RtTests >> Warning: S3 methods 'summary.RtTestSetResults', >> 'print.RtTestSetResults', >> 'print.RtTestSetResults.summary' were declared in NAMESPACE but not >> found >> Error in namespaceExport(ns, exports) : >> undefined exports: parseTranscriptFile, compareTranscriptAndOutput >> Error: package 'RtTests' could not be loaded >> Execution halted >> >> It is true that RtTests declares the various functions in its name >> space, but >> why can they suddenly not be found? If I load RtTests by itself, i.e. >> library(RtTests), there is no problem. >> >> I happen to have all this working under Linux, so I tracked down the >> difference. >> Turns out that under Linux the equivalent to the "lazyload" target is in >> "/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to >> "tools:::makeLazyLoading". Under Linux the full package name with >> version number >> is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests". >> >> So I managed to fix the problem by making Windows use the full >> package name in >> the "lazyload" target. I replaced >> tools:::makeLazyLoading(\"$(PKG)\" >> with >> tools:::makeLazyLoading(\"$(notdir $(DPKG))\" >> >> If I now reinstall "RtTests", I can finally install "RtTestsEG1". >> >> I must confess, that I do not fully understand exactly what it takes to >> reproduce this problem. I am guessing that all it takes is a package >> depending >> on a versioned package. Maybe the similarity in names introduces a >> problem >> because of partial matching. I am guessing that has nothing to do >> with it. >> >> To sum up the report. I see two problems: >> >> 1) LC_ALL=C causes infinite recursion. It is as if the C locale does >> not work >> under Windows. I do not know what the fix is. It is used many places >> in install >> scripts and makefiles. Fixing it in the "lazyload" target is not >> enough. Even >> with my change I still get "infinite recursion" and no error message >> if I try to >> install "RtTestsEG1" without first installing "RtTests". >> >> 2) "makeLazyLoading()" in "lazyload" target needs to be called with >> full package >> name with embedded version number. I think this is bug under Windows >> and my fix >> takes care of it. >> >> It took some time to figure this out. I am hoping this report will >> save other >> people time. I am note sure if I succeeded in describing the problem >> clearly. >> Please do not hesitate to ask for clarification. >> >> Thanks, >> Lars Hansen >> >> P.S. >>> sessionInfo() >> R version 2.8.0 Patched (2008-10-22 r46776) >> i386-pc-mingw32 >> >> locale: >> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United >> States.1252;LC_MONETARY=English_United >> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From simon.urbanek at r-project.org Fri Nov 14 00:47:38 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Thu, 13 Nov 2008 18:47:38 -0500 Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: <491CB41F.503@acm.org> References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> <491CB41F.503@acm.org> Message-ID: On Nov 13, 2008, at 6:11 PM, Tony Plate wrote: > Thanks for the response. > > Are the problems with versioned installs fundamental, or are they > just a case of incomplete implementation and rough edges? > If the latter, would fixes be considered? > > I ask because we would find versioned installs very useful in > maintaining stable production systems, each of which might run with > different versions of various packages, while making it easy to > continually develop and refine our packages. As a point of info, > our primary use for versioning would be with our own packages, so we > could probably get away without using versioned installs for base or > contributed packages. > I find it more useful to work with multiple library paths (.libPaths()) than versioning packages in the above scenario. We usually maintain "stable" package library which is individually overridden by additional paths added by the user (e.g. developer library for testing) and/or subsystems. The override can also be revertive, i.e. a subsystem is free to use older packages in its library than the stable library when desired. Cheers, S > However, if the problems with versioned installs are not amenable to > the kinds of fixes that users can contribute, then I guess we should > look for a different approach. > > Suggestions and comments are welcome! Do many people use versioned > installs? > > -- Tony Plate (coworker of Lars @ blackmesacapital.com) > > Prof Brian Ripley wrote: >> Installing versioned packages is not supported with namespaces. I >> have suggested from time to time that versioned installs be removed >> because of this and other known issues, and recommend that you do >> not attempt to use them. >> >> On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: >> >>> Full_Name: Lars Hansen >>> Version: 2.8.0 >>> OS: Windows XP Pro x64 SP2 >>> Submission from: (NULL) (71.39.177.36) >>> >>> >>> Hi, >>> >>> I have run into a problem using "R CMD INSTALL" with the >>> "--with-package-versions" option under Windows. It is a bit >>> obscure, which could >>> explain why other people have not run into it. >>> >>> We happen to have two packages with almost the same name. One name >>> is a subset >>> of the other. The names are "RtTests" and "RtTestsEG1". I have no >>> problem >>> installing "RtTests" and many other packages, but run into >>> problems installing >>> "RtTestsEG1". The "RtTestsEG1" package happens to be a simple >>> example of how to >>> use the "RtTests" package, so it depends on "RtTests" (which is >>> probably the >>> problem). >>> >>> OK, so this is what happens when I attempt to install "RtTestsEG1": >>> >>> $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 >>> >>> installing RtTestsEG1 package >>> >>> ---------- Making package RtTestsEG1 ------------ >>> adding build stamp to DESCRIPTION >>> installing R files >>> preparing package RtTestsEG1 for lazy loading >>> Loading required package: RtTests >>> ... [lost of lines removed] >>> Loading required package: RtTests >>> Error: evaluation nested too deeply: infinite recursion / >>> options(expressions=)? >>> Execution halted >>> make[2]: *** [lazyload] Error 1 >>> make[1]: *** [all] Error 2 >>> make: *** [pkg-RtTestsEG1] Error 2 >>> *** Installation of RtTestsEG1 failed *** >>> >>> After some digging in the Windows makefiles, I found out that >>> changing the >>> locale from "C" to "us" in the "lazyload" target of >>> $R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of >>> "LC_ALL=C", >>> solves the infinite recursion problem and give an useful message. >>> It still fails >>> but now says: >>> >>> Loading required package: RtTests >>> Warning: S3 methods 'summary.RtTestSetResults', >>> 'print.RtTestSetResults', >>> 'print.RtTestSetResults.summary' were declared in NAMESPACE but >>> not found >>> Error in namespaceExport(ns, exports) : >>> undefined exports: parseTranscriptFile, compareTranscriptAndOutput >>> Error: package 'RtTests' could not be loaded >>> Execution halted >>> >>> It is true that RtTests declares the various functions in its name >>> space, but >>> why can they suddenly not be found? If I load RtTests by itself, >>> i.e. >>> library(RtTests), there is no problem. >>> >>> I happen to have all this working under Linux, so I tracked down >>> the difference. >>> Turns out that under Linux the equivalent to the "lazyload" target >>> is in >>> "/usr/lib/R/bin/INSTALL" and the difference is in the argument >>> passed to >>> "tools:::makeLazyLoading". Under Linux the full package name with >>> version number >>> is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests". >>> >>> So I managed to fix the problem by making Windows use the full >>> package name in >>> the "lazyload" target. I replaced >>> tools:::makeLazyLoading(\"$(PKG)\" >>> with >>> tools:::makeLazyLoading(\"$(notdir $(DPKG))\" >>> >>> If I now reinstall "RtTests", I can finally install "RtTestsEG1". >>> >>> I must confess, that I do not fully understand exactly what it >>> takes to >>> reproduce this problem. I am guessing that all it takes is a >>> package depending >>> on a versioned package. Maybe the similarity in names introduces a >>> problem >>> because of partial matching. I am guessing that has nothing to do >>> with it. >>> >>> To sum up the report. I see two problems: >>> >>> 1) LC_ALL=C causes infinite recursion. It is as if the C locale >>> does not work >>> under Windows. I do not know what the fix is. It is used many >>> places in install >>> scripts and makefiles. Fixing it in the "lazyload" target is not >>> enough. Even >>> with my change I still get "infinite recursion" and no error >>> message if I try to >>> install "RtTestsEG1" without first installing "RtTests". >>> >>> 2) "makeLazyLoading()" in "lazyload" target needs to be called >>> with full package >>> name with embedded version number. I think this is bug under >>> Windows and my fix >>> takes care of it. >>> >>> It took some time to figure this out. I am hoping this report will >>> save other >>> people time. I am note sure if I succeeded in describing the >>> problem clearly. >>> Please do not hesitate to ask for clarification. >>> >>> Thanks, >>> Lars Hansen >>> >>> P.S. >>>> sessionInfo() >>> R version 2.8.0 Patched (2008-10-22 r46776) >>> i386-pc-mingw32 >>> >>> locale: >>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United >>> States.1252;LC_MONETARY=English_United >>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 >>> >>> attached base packages: >>> [1] stats graphics grDevices utils datasets methods base >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From murdoch at stats.uwo.ca Fri Nov 14 00:51:07 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 18:51:07 -0500 Subject: [Rd] R crashes on sprintf with bad format specification (PR#13283) In-Reply-To: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk> References: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk> Message-ID: <491CBD6B.5000300@stats.uwo.ca> On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: > Full_Name: Oren Cheyette > Version: 2.7.2 > OS: Win XP > Submission from: (NULL) (64.161.123.194) > > > Enter the following at the R command prompt: >> sprintf("A %S %S %S XYZ", 1, 1, 1); > > Note the erroneous capitalized %S instead of %s and the numeric inputs instead > of strings. With strings there's no crash - R reports bad format > specifications. 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent R-devel. The last few entries in the stack dump at the time of the crash are shown below; these make it look as though the problem is in the Trio library, so it may be hard to fix. Duncan Murdoch Rgui.exe caused an Access Violation at location 6c913fb3 in module R.dll Reading from location 00000001. Registers: eax=7fffffff ebx=00000000 ecx=00e17b21 edx=00000001 esi=00e1c83b edi=0000000a eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 Call stack: 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 ... while (length > 0) { > size = TrioWriteWideStringCharacter(self, *wstring++, flags, length); if (size == 0) break; /* while */ ... 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 ... return status; > status = TrioFormatProcess(&data, format, parameters); if (data.error != 0) { ... 6C911F62 R.dll:6C911F62 sprintf compat.c:46 ... va_end(ap); return res; > } ... 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 ... sprintf(bit, fmtp, " NaN"); else > sprintf(bit, fmtp, "NaN"); } else if (x == R_PosInf) { if (strcspn(fmtp, "+") < strlen(fmtp)) ... From murdoch at stats.uwo.ca Fri Nov 14 01:00:07 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Thu, 13 Nov 2008 19:00:07 -0500 Subject: [Rd] Documentation error in Writing R Extensions (PR#13282) In-Reply-To: <20081112230508.74FB2282EFC1@mail.pubhealth.ku.dk> References: <20081112230508.74FB2282EFC1@mail.pubhealth.ku.dk> Message-ID: <491CBF87.7090600@stats.uwo.ca> On 12/11/2008 6:05 PM, pdunn2 at usc.edu.au wrote: > Full_Name: Peter K Dunn > Version: NA > OS: NA > Submission from: (NULL) (203.29.106.59) > > > Reading the manual "Writing R Extensions", the html and pdf versions both > contain important typos in Section 1.10. As an example: > > > An installed file named ?CTIATION? will be used by the citation() function. .. > > > > The word CTIATION presumably should be CITATION. This occurs four times in > Section 1.10, even though the section is called CITATION files. Thanks, I'll fix those. Duncan Murdoch From seth at userprimary.net Fri Nov 14 01:42:18 2008 From: seth at userprimary.net (Seth Falcon) Date: Thu, 13 Nov 2008 16:42:18 -0800 Subject: [Rd] R crashes on sprintf with bad format specification (PR#13283) In-Reply-To: <491CBD6B.5000300@stats.uwo.ca> References: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk> <491CBD6B.5000300@stats.uwo.ca> Message-ID: <20081114004218.GZ71797@ziti.local> * On 2008-11-13 at 18:51 -0500 Duncan Murdoch wrote: > On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: >> Full_Name: Oren Cheyette >> Version: 2.7.2 >> OS: Win XP >> Submission from: (NULL) (64.161.123.194) >> >> >> Enter the following at the R command prompt: >>> sprintf("A %S %S %S XYZ", 1, 1, 1); >> >> Note the erroneous capitalized %S instead of %s and the numeric inputs instead >> of strings. With strings there's no crash - R reports bad format >> specifications. > > 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent > R-devel. Can confirm as well on OSX with a fairly recent R-devel. (gdb) bt 10 #0 0x9575e299 in _UTF8_wcsnrtombs () #1 0x957bb3a0 in wcsrtombs_l () #2 0x956ebc1e in __vfprintf () #3 0x95711e66 in sprintf () #4 0x00492bb8 in do_sprintf (call=0x10cb470, op=0x1018924, args=, env=0x10a40b0) at ../../../../R-devel-all/src/main/sprintf.c:179 #5 0x003fe1af in do_internal (call=0x10cb4a8, op=0x100fc38, args=0x10a40e8, env=0x10a40b0) at ../../../../R-devel-all/src/main/names.c:1140 + seth -- Seth Falcon | http://userprimary.net/user/ From seth at userprimary.net Fri Nov 14 01:45:03 2008 From: seth at userprimary.net (seth at userprimary.net) Date: Fri, 14 Nov 2008 01:45:03 +0100 (CET) Subject: [Rd] R crashes on sprintf with bad format specification (PR#13285) Message-ID: <20081114004503.EE630282EFF6@mail.pubhealth.ku.dk> * On 2008-11-13 at 18:51 -0500 Duncan Murdoch wrote: > On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: >> Full_Name: Oren Cheyette >> Version: 2.7.2 >> OS: Win XP >> Submission from: (NULL) (64.161.123.194) >> >> >> Enter the following at the R command prompt: >>> sprintf("A %S %S %S XYZ", 1, 1, 1); >> >> Note the erroneous capitalized %S instead of %s and the numeric inputs instead >> of strings. With strings there's no crash - R reports bad format >> specifications. > > 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent > R-devel. Can confirm as well on OSX with a fairly recent R-devel. (gdb) bt 10 #0 0x9575e299 in _UTF8_wcsnrtombs () #1 0x957bb3a0 in wcsrtombs_l () #2 0x956ebc1e in __vfprintf () #3 0x95711e66 in sprintf () #4 0x00492bb8 in do_sprintf (call=0x10cb470, op=0x1018924, args=, env=0x10a40b0) at ../../../../R-devel-all/src/main/sprintf.c:179 #5 0x003fe1af in do_internal (call=0x10cb4a8, op=0x100fc38, args=0x10a40e8, env=0x10a40b0) at ../../../../R-devel-all/src/main/names.c:1140 + seth -- Seth Falcon | http://userprimary.net/user/ From spluque at gmail.com Fri Nov 14 07:29:22 2008 From: spluque at gmail.com (Sebastian P. Luque) Date: Fri, 14 Nov 2008 00:29:22 -0600 Subject: [Rd] multiple item lists in value section of *.Rd Message-ID: <874p2azupp.fsf@patagonia.sebmags.homelinux.org> Hi, If an *.Rd file documents more than one object, and each object returns several objects, which should ideally be described in an itemized list. When documenting single objects, I've been doing this using simple \item(s) inside the value section, like: \value{This function returns: \item{1st}{one} \item{2nd}{two.} } How should more than one itemized list be written? The manual says that a small introductory phrase can precede the \item(s), but it doesn't show what to do when we have 2 lists, requiring 2 introductory phrases. Something like: \value{One function returns: \item{1st}{one} \item{2nd}{two.} Another function returns: \item{1st}{one} \item{2nd}{two.} } Any suggestions welcome. Cheers, -- Seb From felix at nfrac.org Fri Nov 14 08:27:15 2008 From: felix at nfrac.org (Felix Andrews) Date: Fri, 14 Nov 2008 18:27:15 +1100 Subject: [Rd] grid error: protection stack overflow Message-ID: <94730b8a0811132327g1ee7691ajdc5c41d61dd14bb4@mail.gmail.com> I have isolated an error that can be reproduced by the following code. The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the try() code is ending up in the display list, or something? library(grid) library(lattice) xyplot(1:100 ~ 1:100) test <- try(downViewport("pageAnnotationVp"), silent = TRUE) downViewport(trellis.vpname("toplevel")) pushViewport(viewport(name = "pageAnnotationVp", yscale = c(1, 0))) upViewport(0) ## resize device to trigger a couple of redraws... Error: protect(): protection stack overflow Enter a frame number, or 0 to exit 1: no.children() 2: ls(children, all.names = TRUE) 3: try(name) 4: tryCatch(expr, error = function(e) { 5: tryCatchList(expr, classes, parentenv, handlers) 6: tryCatchOne(expr, names, parentenv, handlers[[1]]) 7: doTryCatch(return(expr), name, parentenv, handler) > sessionInfo() R version 2.8.0 Patched (2008-11-10 r46884) i386-pc-mingw32 locale: LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 attached base packages: [1] grid stats graphics grDevices utils datasets methods base other attached packages: [1] lattice_0.17-15 -- Felix Andrews / ??? http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 From felix at nfrac.org Fri Nov 14 08:59:54 2008 From: felix at nfrac.org (Felix Andrews) Date: Fri, 14 Nov 2008 18:59:54 +1100 Subject: [Rd] grid error: protection stack overflow In-Reply-To: <94730b8a0811132327g1ee7691ajdc5c41d61dd14bb4@mail.gmail.com> References: <94730b8a0811132327g1ee7691ajdc5c41d61dd14bb4@mail.gmail.com> Message-ID: <94730b8a0811132359r2e470497g5c8555def5532826@mail.gmail.com> For the record, a much better alternative to try(downViewport()) is curVps <- grid.ls(grobs = FALSE, viewports = TRUE, print = FALSE)$name if ("fooVp" %in% curVps) ... 2008/11/14 Felix Andrews : > I have isolated an error that can be reproduced by the following code. > The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the > try() code is ending up in the display list, or something? > > library(grid) > library(lattice) > > xyplot(1:100 ~ 1:100) > test <- try(downViewport("pageAnnotationVp"), silent = TRUE) > downViewport(trellis.vpname("toplevel")) > pushViewport(viewport(name = "pageAnnotationVp", yscale = c(1, 0))) > upViewport(0) > > ## resize device to trigger a couple of redraws... > > Error: protect(): protection stack overflow > > Enter a frame number, or 0 to exit > 1: no.children() > 2: ls(children, all.names = TRUE) > 3: try(name) > 4: tryCatch(expr, error = function(e) { > 5: tryCatchList(expr, classes, parentenv, handlers) > 6: tryCatchOne(expr, names, parentenv, handlers[[1]]) > 7: doTryCatch(return(expr), name, parentenv, handler) > > >> sessionInfo() > R version 2.8.0 Patched (2008-11-10 r46884) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 > > attached base packages: > [1] grid stats graphics grDevices utils datasets > methods base > > other attached packages: > [1] lattice_0.17-15 > > > -- > Felix Andrews / ??? > http://www.neurofractal.org/felix/ > 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 > -- Felix Andrews / ??? http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 From ripley at stats.ox.ac.uk Fri Nov 14 09:04:10 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 08:04:10 +0000 (GMT) Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> <491CB41F.503@acm.org> Message-ID: On Thu, 13 Nov 2008, Simon Urbanek wrote: > On Nov 13, 2008, at 6:11 PM, Tony Plate wrote: > >> Thanks for the response. >> >> Are the problems with versioned installs fundamental, or are they just a >> case of incomplete implementation and rough edges? >> If the latter, would fixes be considered? >> >> I ask because we would find versioned installs very useful in maintaining >> stable production systems, each of which might run with different versions >> of various packages, while making it easy to continually develop and refine >> our packages. As a point of info, our primary use for versioning would be >> with our own packages, so we could probably get away without using >> versioned installs for base or contributed packages. >> > > I find it more useful to work with multiple library paths (.libPaths()) than > versioning packages in the above scenario. We usually maintain "stable" > package library which is individually overridden by additional paths added by > the user (e.g. developer library for testing) and/or subsystems. The override > can also be revertive, i.e. a subsystem is free to use older packages in its > library than the stable library when desired. So do I. If you have versioned installs, the highest version will be chosen unless you specify otherwise, and there is no way to specify a version in common mechanisms like Depends:, Imports: in the DESCRIPTION file and imports()/importsFrom() in the namespace. Even if a package uses requires(), you can only specify a particular version, not a range of versions. So using different library trees is a much more general mechanism. As far as I understand, the main point of versioned installs was to be able to load different versions of a package in the same R session, so packages A and B could depend on different versions of package C. As namespaces are not versioned, this cannot be done with packages with namespaces (there are other issues too). We've known that for a long time, and no one has been motivated to fix it (and it would need extensive changes). It is way beyond anything we would accept non-R-core patches for. It would be possible to fix up the lack of implementation of versioned installs on Windows (which are much more extensive than in this bug report). But given that the lack has been there for several years and no user seems to have noticed it, it seems a waste of effort to do so. The plan is to move INSTALL on both Unix and Windows to a common R script, and that is unlikely to support versioned installs. There are on-going discussions in R-core, but the likely outcome is to deprecate versioned installs in the near future. > > Cheers, > S > > >> However, if the problems with versioned installs are not amenable to the >> kinds of fixes that users can contribute, then I guess we should look for a >> different approach. >> >> Suggestions and comments are welcome! Do many people use versioned >> installs? >> >> -- Tony Plate (coworker of Lars @ blackmesacapital.com) >> >> Prof Brian Ripley wrote: >>> Installing versioned packages is not supported with namespaces. I have >>> suggested from time to time that versioned installs be removed because of >>> this and other known issues, and recommend that you do not attempt to use >>> them. >>> >>> On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: >>> >>>> Full_Name: Lars Hansen >>>> Version: 2.8.0 >>>> OS: Windows XP Pro x64 SP2 >>>> Submission from: (NULL) (71.39.177.36) >>>> >>>> >>>> Hi, >>>> >>>> I have run into a problem using "R CMD INSTALL" with the >>>> "--with-package-versions" option under Windows. It is a bit obscure, >>>> which could >>>> explain why other people have not run into it. >>>> >>>> We happen to have two packages with almost the same name. One name is a >>>> subset >>>> of the other. The names are "RtTests" and "RtTestsEG1". I have no >>>> problem >>>> installing "RtTests" and many other packages, but run into problems >>>> installing >>>> "RtTestsEG1". The "RtTestsEG1" package happens to be a simple example of >>>> how to >>>> use the "RtTests" package, so it depends on "RtTests" (which is probably >>>> the >>>> problem). >>>> >>>> OK, so this is what happens when I attempt to install "RtTestsEG1": >>>> >>>> $ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1 >>>> >>>> installing RtTestsEG1 package >>>> >>>> ---------- Making package RtTestsEG1 ------------ >>>> adding build stamp to DESCRIPTION >>>> installing R files >>>> preparing package RtTestsEG1 for lazy loading >>>> Loading required package: RtTests >>>> ... [lost of lines removed] >>>> Loading required package: RtTests >>>> Error: evaluation nested too deeply: infinite recursion / >>>> options(expressions=)? >>>> Execution halted >>>> make[2]: *** [lazyload] Error 1 >>>> make[1]: *** [all] Error 2 >>>> make: *** [pkg-RtTestsEG1] Error 2 >>>> *** Installation of RtTestsEG1 failed *** >>>> >>>> After some digging in the Windows makefiles, I found out that changing >>>> the >>>> locale from "C" to "us" in the "lazyload" target of >>>> $R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of >>>> "LC_ALL=C", >>>> solves the infinite recursion problem and give an useful message. It >>>> still fails >>>> but now says: >>>> >>>> Loading required package: RtTests >>>> Warning: S3 methods 'summary.RtTestSetResults', 'print.RtTestSetResults', >>>> 'print.RtTestSetResults.summary' were declared in NAMESPACE but not found >>>> Error in namespaceExport(ns, exports) : >>>> undefined exports: parseTranscriptFile, compareTranscriptAndOutput >>>> Error: package 'RtTests' could not be loaded >>>> Execution halted >>>> >>>> It is true that RtTests declares the various functions in its name space, >>>> but >>>> why can they suddenly not be found? If I load RtTests by itself, i.e. >>>> library(RtTests), there is no problem. >>>> >>>> I happen to have all this working under Linux, so I tracked down the >>>> difference. >>>> Turns out that under Linux the equivalent to the "lazyload" target is in >>>> "/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to >>>> "tools:::makeLazyLoading". Under Linux the full package name with version >>>> number >>>> is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests". >>>> >>>> So I managed to fix the problem by making Windows use the full package >>>> name in >>>> the "lazyload" target. I replaced >>>> tools:::makeLazyLoading(\"$(PKG)\" >>>> with >>>> tools:::makeLazyLoading(\"$(notdir $(DPKG))\" >>>> >>>> If I now reinstall "RtTests", I can finally install "RtTestsEG1". >>>> >>>> I must confess, that I do not fully understand exactly what it takes to >>>> reproduce this problem. I am guessing that all it takes is a package >>>> depending >>>> on a versioned package. Maybe the similarity in names introduces a >>>> problem >>>> because of partial matching. I am guessing that has nothing to do with >>>> it. >>>> >>>> To sum up the report. I see two problems: >>>> >>>> 1) LC_ALL=C causes infinite recursion. It is as if the C locale does not >>>> work >>>> under Windows. I do not know what the fix is. It is used many places in >>>> install >>>> scripts and makefiles. Fixing it in the "lazyload" target is not enough. >>>> Even >>>> with my change I still get "infinite recursion" and no error message if I >>>> try to >>>> install "RtTestsEG1" without first installing "RtTests". >>>> >>>> 2) "makeLazyLoading()" in "lazyload" target needs to be called with full >>>> package >>>> name with embedded version number. I think this is bug under Windows and >>>> my fix >>>> takes care of it. >>>> >>>> It took some time to figure this out. I am hoping this report will save >>>> other >>>> people time. I am note sure if I succeeded in describing the problem >>>> clearly. >>>> Please do not hesitate to ask for clarification. >>>> >>>> Thanks, >>>> Lars Hansen >>>> >>>> P.S. >>>>> sessionInfo() >>>> R version 2.8.0 Patched (2008-10-22 r46776) >>>> i386-pc-mingw32 >>>> >>>> locale: >>>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United >>>> States.1252;LC_MONETARY=English_United >>>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 >>>> >>>> attached base packages: >>>> [1] stats graphics grDevices utils datasets methods base >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From maechler at stat.math.ethz.ch Fri Nov 14 09:48:51 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Fri, 14 Nov 2008 09:48:51 +0100 Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> <491CB41F.503@acm.org> Message-ID: <18717.15219.178923.14858@stat.math.ethz.ch> >>>>> "SU" == Simon Urbanek >>>>> on Thu, 13 Nov 2008 18:47:38 -0500 writes: SU> On Nov 13, 2008, at 6:11 PM, Tony Plate wrote: >> Thanks for the response. >> >> Are the problems with versioned installs fundamental, or >> are they just a case of incomplete implementation and >> rough edges? If the latter, would fixes be considered? >> >> I ask because we would find versioned installs very >> useful in maintaining stable production systems, each of >> which might run with different versions of various >> packages, while making it easy to continually develop and >> refine our packages. As a point of info, our primary use >> for versioning would be with our own packages, so we >> could probably get away without using versioned installs >> for base or contributed packages. >> SU> I find it more useful to work with multiple library paths SU> (.libPaths()) than versioning packages in the above SU> scenario. We usually maintain "stable" package library SU> which is individually overridden by additional paths SU> added by the user (e.g. developer library for testing) SU> and/or subsystems. The override can also be revertive, SU> i.e. a subsystem is free to use older packages in its SU> library than the stable library when desired. We use the same "technique", both using the R_LIBS environment variable, and also amending it in an .Rprofile equivalent depending on the version of R (or the user), i.e., something like libPIns <- function(nlib, beforeLib, msgTxt) { ## Purpose: Insert a directory into .libPaths() *before* another one ## ---------------------------------------------------------------- ## Arguments: nlib: The library directory to insert ## beforeLib: (grep-pattern of an) entry in current .libPaths() ## msgTxt: optional message text about the insertion ## ---------------------------------------------------------------- ## Author: Martin Maechler, 2006 if(file.exists(nlib)) { if(length({fl <- list.files(nlib); fl[fl != "R.css"]})) { ## only if the library contains any packages : if(!missing(msgTxt) && is.character(msgTxt)) cat("extending .libPaths()", msgTxt,"...\n") ni <- length(iL <- grep(beforeLib, lp <- .libPaths())) if(ni != 1) { warning(".libPaths() contains ", if(ni>1) "more" else "no", " entries matching ",sQuote(beforeLib)) iL <- if(ni > 1) iL[1] else length(lp) cat("Inserting before position", iL,"..\n") } ii <- 1:length(lp) .libPaths(c(lp[ii < iL], nlib, lp[ii >= iL])) } } else warning(nlib, " is not an existing directory") } and then somewhere RVersion <- paste(R.version$major, R.version$minor, sep=".") Rstat <- R.version$status is.Rdevel <- ## Rstat == "beta" || length(grep("devel", Rstat)) > 0 if(is.Rdevel) libPIns(nlib = file.path(RrootDir,"library-R-devel"), beforeLib = file.path(RrootDir,"library"), msgTxt = "for 'R-devel'") and other such if(.....) libPIns(....) calls. Martin Maechler, ETH Zurich >> However, if the problems with versioned installs are not >> amenable to the kinds of fixes that users can contribute, >> then I guess we should look for a different approach. >> >> Suggestions and comments are welcome! Do many people use >> versioned installs? >> >> -- Tony Plate (coworker of Lars @ blackmesacapital.com) >> >> Prof Brian Ripley wrote: >>> Installing versioned packages is not supported with >>> namespaces. I have suggested from time to time that >>> versioned installs be removed because of this and other >>> known issues, and recommend that you do not attempt to >>> use them. >>> >>> On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: >>> >>>> Full_Name: Lars Hansen Version: 2.8.0 OS: Windows XP >>>> Pro x64 SP2 Submission from: (NULL) (71.39.177.36) >>>> >>>> >>>> Hi, >>>> >>>> I have run into a problem using "R CMD INSTALL" with >>>> the "--with-package-versions" option under Windows. It >>>> is a bit obscure, which could explain why other people >>>> have not run into it. >>>> >>>> We happen to have two packages with almost the same >>>> name. One name is a subset of the other. The names are >>>> "RtTests" and "RtTestsEG1". I have no problem >>>> installing "RtTests" and many other packages, but run >>>> into problems installing "RtTestsEG1". The "RtTestsEG1" >>>> package happens to be a simple example of how to use >>>> the "RtTests" package, so it depends on "RtTests" >>>> (which is probably the problem). >>>> >>>> OK, so this is what happens when I attempt to install >>>> "RtTestsEG1": >>>> >>>> $ R CMD INSTALL --with-package-versions >>>> --library=$R_LIBS RtTestsEG1 >>>> >>>> installing RtTestsEG1 package >>>> >>>> ---------- Making package RtTestsEG1 ------------ >>>> adding build stamp to DESCRIPTION installing R files >>>> preparing package RtTestsEG1 for lazy loading Loading >>>> required package: RtTests ... [lost of lines removed] >>>> Loading required package: RtTests Error: evaluation >>>> nested too deeply: infinite recursion / >>>> options(expressions=)? Execution halted make[2]: *** >>>> [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** >>>> [pkg-RtTestsEG1] Error 2 *** Installation of RtTestsEG1 >>>> failed *** >>>> >>>> After some digging in the Windows makefiles, I found >>>> out that changing the locale from "C" to "us" in the >>>> "lazyload" target of $R_HOME/src/gnuwin32/MakePkg, >>>> i.e. using "LC_ALL=us" instead of "LC_ALL=C", solves >>>> the infinite recursion problem and give an useful >>>> message. It still fails but now says: >>>> >>>> Loading required package: RtTests Warning: S3 methods >>>> 'summary.RtTestSetResults', 'print.RtTestSetResults', >>>> 'print.RtTestSetResults.summary' were declared in >>>> NAMESPACE but not found Error in namespaceExport(ns, >>>> exports) : undefined exports: parseTranscriptFile, >>>> compareTranscriptAndOutput Error: package 'RtTests' >>>> could not be loaded Execution halted >>>> >>>> It is true that RtTests declares the various functions >>>> in its name space, but why can they suddenly not be >>>> found? If I load RtTests by itself, i.e. >>>> library(RtTests), there is no problem. >>>> >>>> I happen to have all this working under Linux, so I >>>> tracked down the difference. Turns out that under >>>> Linux the equivalent to the "lazyload" target is in >>>> "/usr/lib/R/bin/INSTALL" and the difference is in the >>>> argument passed to "tools:::makeLazyLoading". Under >>>> Linux the full package name with version number is >>>> used, i.e. "RtTests_0.1-1". Windows just uses >>>> "RtTests". >>>> >>>> So I managed to fix the problem by making Windows use >>>> the full package name in the "lazyload" target. I >>>> replaced tools:::makeLazyLoading(\"$(PKG)\" with >>>> tools:::makeLazyLoading(\"$(notdir $(DPKG))\" >>>> >>>> If I now reinstall "RtTests", I can finally install >>>> "RtTestsEG1". >>>> >>>> I must confess, that I do not fully understand exactly >>>> what it takes to reproduce this problem. I am guessing >>>> that all it takes is a package depending on a versioned >>>> package. Maybe the similarity in names introduces a >>>> problem because of partial matching. I am guessing that >>>> has nothing to do with it. >>>> >>>> To sum up the report. I see two problems: >>>> >>>> 1) LC_ALL=C causes infinite recursion. It is as if the >>>> C locale does not work under Windows. I do not know >>>> what the fix is. It is used many places in install >>>> scripts and makefiles. Fixing it in the "lazyload" >>>> target is not enough. Even with my change I still get >>>> "infinite recursion" and no error message if I try to >>>> install "RtTestsEG1" without first installing >>>> "RtTests". >>>> >>>> 2) "makeLazyLoading()" in "lazyload" target needs to be >>>> called with full package name with embedded version >>>> number. I think this is bug under Windows and my fix >>>> takes care of it. >>>> >>>> It took some time to figure this out. I am hoping this >>>> report will save other people time. I am note sure if I >>>> succeeded in describing the problem clearly. Please do >>>> not hesitate to ask for clarification. >>>> >>>> Thanks, Lars Hansen >>>> >>>> P.S. >>>>> sessionInfo() >>>> R version 2.8.0 Patched (2008-10-22 r46776) >>>> i386-pc-mingw32 >>>> >>>> locale: LC_COLLATE=English_United >>>> States.1252;LC_CTYPE=English_United >>>> States.1252;LC_MONETARY=English_United >>>> States.1252;LC_NUMERIC=C;LC_TIME=English_United >>>> States.1252 >>>> >>>> attached base packages: [1] stats graphics grDevices >>>> utils datasets methods base >>>> >>>> ______________________________________________ >>>> R-devel at r-project.org mailing list >>>> https://stat.ethz.ch/mailman/listinfo/r-devel >>>> >>> > > ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> ______________________________________________ SU> R-devel at r-project.org mailing list SU> https://stat.ethz.ch/mailman/listinfo/r-devel From ripley at stats.ox.ac.uk Fri Nov 14 11:24:47 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 10:24:47 +0000 (GMT) Subject: [Rd] (PR#13283) R crashes on sprintf with bad format specification In-Reply-To: <491CBD6B.5000300@stats.uwo.ca> References: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk> <491CBD6B.5000300@stats.uwo.ca> Message-ID: As R's sprintf is a wrapper for the OS's sprintf, misuse does run the risk of crashing from OS, and when it does the error will come from the implementation of sprintf (which for R for Windows is the Trio library). One could argue that the OS service should not segfault on incorrect input, but this one often does. The place to add checks is in the R wrapper code (presumably in the C component). We do have checks there, but it is hard to imagine just what errors users will make, and this one has slipped through the checks. Here the issue is the use of %S, an unknown format for numbers, followed by 'X'. There is a check for a suitable format, but it is not strict enough. And it is non-trivial to write a printf format parser just to check for user error (and potentially it will slow down correct uses: speed in sprintf is important in some applications). So I am not sure this is something that should be R's responsibility to fix: maybe just add a warning to the help page? On Thu, 13 Nov 2008, Duncan Murdoch wrote: > On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: >> Full_Name: Oren Cheyette >> Version: 2.7.2 >> OS: Win XP >> Submission from: (NULL) (64.161.123.194) >> >> >> Enter the following at the R command prompt: >>> sprintf("A %S %S %S XYZ", 1, 1, 1); R is not C, and the empty command at the end of that line (after the semicolon) is not relevant. >> Note the erroneous capitalized %S instead of %s and the numeric inputs >> instead >> of strings. With strings there's no crash - R reports bad format >> specifications. > > 2.7.2 is obsolete, but I can confirm a crash on Windows with a recent > R-devel. > > The last few entries in the stack dump at the time of the crash are shown > below; these make it look as though the problem is in the Trio library, so it > may be hard to fix. > > Duncan Murdoch > > > Rgui.exe caused an Access Violation at location 6c913fb3 in module R.dll > Reading from location 00000001. > > Registers: > eax=7fffffff ebx=00000000 ecx=00e17b21 edx=00000001 esi=00e1c83b edi=0000000a > eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up ei pl nz na po nc > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 > > Call stack: > 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 > > ... > while (length > 0) > { >> size = TrioWriteWideStringCharacter(self, *wstring++, flags, > length); > if (size == 0) > break; /* while */ > ... > > 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 > > ... > return status; > >> status = TrioFormatProcess(&data, format, parameters); > if (data.error != 0) > { > ... > > 6C911F62 R.dll:6C911F62 sprintf compat.c:46 > > ... > va_end(ap); > return res; >> } > > > ... > > 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 > > ... > sprintf(bit, fmtp, " NaN"); > else >> sprintf(bit, fmtp, "NaN"); > } else if (x == R_PosInf) { > if (strcspn(fmtp, "+") < strlen(fmtp)) > ... > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From edd at debian.org Fri Nov 14 15:15:04 2008 From: edd at debian.org (edd at debian.org) Date: Fri, 14 Nov 2008 15:15:04 +0100 (CET) Subject: [Rd] Bug#505698: r-base-core: dev2bitmap fails with gsexe related error (PR#13288) Message-ID: <20081114141504.8098C2834153@mail.pubhealth.ku.dk> Stefano, Thanks for the bug report. On 14 November 2008 at 14:35, Stefano Costa wrote: | Package: r-base-core | Version: 2.8.0-1 | Severity: normal | | As in subject. The bug is reproducible on my machine with these | commands: | | > x <- rnorm(100) | > plot(density(x)) | > dev2bitmap("density.png") | Error in paste(shQuote(gsexe), " -dNOPAUSE -dBATCH -q -sDEVICE=", type, | : | object "extra" not found | > Confirmed. The code in looks a little off inasmuch as in if (!is.na(taa)) extra <- paste(" -dTextAlphaBits=", taa, sep = "") if (!is.na(gaa)) extra <- paste(extra, " -dGraphicsAlphaBits=", gaa, sep = "") cmd <- paste(shQuote(gsexe), " -dNOPAUSE -dBATCH -q -sDEVICE=", type, " -r", res, "-dAutoRotatePages=/None", " -g", ceiling(res * width), "x", ceiling(res * height), extra, " -sOutputFile=", shQuote(file), " ", tmp, sep = "") system(cmd) 'extra' does get set if and only if taa or gaa are given. Adding a simple extra <- "" before the quoted code block fixes the trivial bug. I am CC'ing upstream. All that said, you may also want to consider the somewhat better usage of x <- rnorm(100) png("density.png") ## also see additional png arguments plot(density(x)) dev.off() to create density.png. Thanks, Dirk | | | Best, | Steko | | | | -- System Information: | Debian Release: lenny/sid | APT prefers unstable | APT policy: (500, 'unstable'), (101, 'experimental') | Architecture: amd64 (x86_64) | | Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) | Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) | Shell: /bin/sh linked to /bin/dash | | Versions of packages r-base-core depends on: | ii libatlas3gf-base [libl 3.6.0-22 Automatically Tuned Linear Algebra | ii libblas3gf [libblas.so 1.2-2 Basic Linear Algebra Subroutines 3 | ii libc6 2.7-16 GNU C Library: Shared libraries | ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra | ii libgfortran3 4.3.2-1 Runtime library for GNU Fortran ap | ii libglib2.0-0 2.16.6-1 The GLib library of C routines | ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library | ii libjpeg62 6b-14 The Independent JPEG Group's JPEG | ii liblapack3gf [liblapac 3.1.1-6 library of linear algebra routines | ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio | ii libpaper-utils 1.1.23+nmu1 library for handling paper charact | ii libpcre3 7.8-2 Perl 5 Compatible Regular Expressi | ii libpng12-0 1.2.27-2 PNG library - runtime | ii libreadline5 5.2-3 GNU readline and history libraries | ii libsm6 2:1.0.3-2 X11 Session Management library | ii libtiff4 3.8.2-11 Tag Image File Format (TIFF) libra | ii libx11-6 2:1.1.5-2 X11 client-side library | ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar | ii libxss1 1:1.1.3-1 X11 Screen Saver extension library | ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library | ii perl 5.10.0-17 Larry Wall's Practical Extraction | ii tcl8.5 8.5.3-2 Tcl (the Tool Command Language) v8 | ii tk8.5 8.5.3-4 Tk toolkit for Tcl and X11, v8.5 - | ii ucf 3.0010 Update Configuration File: preserv | ii unzip 5.52-12 De-archiver for .zip files | ii zip 2.32-1 Archiver for .zip files | ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime | | Versions of packages r-base-core recommends: | ii r-base-dev 2.8.0-1 GNU R installation of auxiliary GN | ii r-recommended 2.8.0-1 GNU R collection of recommended pa | | Versions of packages r-base-core suggests: | pn ess (no description available) | ii r-base-html 2.8.0-1 GNU R html docs for statistical co | ii r-base-latex 2.8.0-1 GNU R LaTeX docs for statistical c | pn r-doc-info | r-doc-pdf | r-do (no description available) | pn r-mathlib (no description available) | | -- no debconf information | | -- Three out of two people have difficulties with fractions. From ripley at stats.ox.ac.uk Fri Nov 14 15:37:11 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 14:37:11 +0000 (GMT) Subject: [Rd] (PR#13288) Bug#505698: r-base-core: dev2bitmap fails with gsexe related error In-Reply-To: <20081114141504.8098C2834153@mail.pubhealth.ku.dk> References: <20081114141504.8098C2834153@mail.pubhealth.ku.dk> Message-ID: >From the NEWS for R-patched o dev2bitmap() failed in 2.8.0 if 'taa' and 'gaa' were both NA. so this was already fixed. On Fri, 14 Nov 2008, edd at debian.org wrote: > > Stefano, > > Thanks for the bug report. > > On 14 November 2008 at 14:35, Stefano Costa wrote: > | Package: r-base-core > | Version: 2.8.0-1 > | Severity: normal > | > | As in subject. The bug is reproducible on my machine with these > | commands: > | > | > x <- rnorm(100) > | > plot(density(x)) > | > dev2bitmap("density.png") > | Error in paste(shQuote(gsexe), " -dNOPAUSE -dBATCH -q -sDEVICE=", type, > | : > | object "extra" not found > | > > > Confirmed. The code in looks a little off inasmuch as in > > if (!is.na(taa)) > extra <- paste(" -dTextAlphaBits=", taa, sep = "") > if (!is.na(gaa)) > extra <- paste(extra, " -dGraphicsAlphaBits=", gaa, sep = "") > cmd <- paste(shQuote(gsexe), " -dNOPAUSE -dBATCH -q -sDEVICE=", > type, " -r", res, "-dAutoRotatePages=/None", " -g", ceiling(res * > width), "x", ceiling(res * height), extra, " -sOutputFile=", > shQuote(file), " ", tmp, sep = "") > system(cmd) > > 'extra' does get set if and only if taa or gaa are given. Adding a simple > > extra <- "" > > before the quoted code block fixes the trivial bug. I am CC'ing upstream. > > All that said, you may also want to consider the somewhat better usage of > > x <- rnorm(100) > png("density.png") ## also see additional png arguments > plot(density(x)) > dev.off() > > to create density.png. > > Thanks, Dirk > > | > | > | Best, > | Steko > | > | > | > | -- System Information: > | Debian Release: lenny/sid > | APT prefers unstable > | APT policy: (500, 'unstable'), (101, 'experimental') > | Architecture: amd64 (x86_64) > | > | Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) > | Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) > | Shell: /bin/sh linked to /bin/dash > | > | Versions of packages r-base-core depends on: > | ii libatlas3gf-base [libl 3.6.0-22 Automatically Tuned Linear Algebra > | ii libblas3gf [libblas.so 1.2-2 Basic Linear Algebra Subroutines 3 > | ii libc6 2.7-16 GNU C Library: Shared libraries > | ii libcairo2 1.6.4-6.1 The Cairo 2D vector graphics libra > | ii libgfortran3 4.3.2-1 Runtime library for GNU Fortran ap > | ii libglib2.0-0 2.16.6-1 The GLib library of C routines > | ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library > | ii libjpeg62 6b-14 The Independent JPEG Group's JPEG > | ii liblapack3gf [liblapac 3.1.1-6 library of linear algebra routines > | ii libpango1.0-0 1.20.5-3 Layout and rendering of internatio > | ii libpaper-utils 1.1.23+nmu1 library for handling paper charact > | ii libpcre3 7.8-2 Perl 5 Compatible Regular Expressi > | ii libpng12-0 1.2.27-2 PNG library - runtime > | ii libreadline5 5.2-3 GNU readline and history libraries > | ii libsm6 2:1.0.3-2 X11 Session Management library > | ii libtiff4 3.8.2-11 Tag Image File Format (TIFF) libra > | ii libx11-6 2:1.1.5-2 X11 client-side library > | ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar > | ii libxss1 1:1.1.3-1 X11 Screen Saver extension library > | ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library > | ii perl 5.10.0-17 Larry Wall's Practical Extraction > | ii tcl8.5 8.5.3-2 Tcl (the Tool Command Language) v8 > | ii tk8.5 8.5.3-4 Tk toolkit for Tcl and X11, v8.5 - > | ii ucf 3.0010 Update Configuration File: preserv > | ii unzip 5.52-12 De-archiver for .zip files > | ii zip 2.32-1 Archiver for .zip files > | ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime > | > | Versions of packages r-base-core recommends: > | ii r-base-dev 2.8.0-1 GNU R installation of auxiliary GN > | ii r-recommended 2.8.0-1 GNU R collection of recommended pa > | > | Versions of packages r-base-core suggests: > | pn ess (no description available) > | ii r-base-html 2.8.0-1 GNU R html docs for statistical co > | ii r-base-latex 2.8.0-1 GNU R LaTeX docs for statistical c > | pn r-doc-info | r-doc-pdf | r-do (no description available) > | pn r-mathlib (no description available) > | > | -- no debconf information > | > | > > -- > Three out of two people have difficulties with fractions. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From edd at debian.org Fri Nov 14 15:54:59 2008 From: edd at debian.org (Dirk Eddelbuettel) Date: Fri, 14 Nov 2008 08:54:59 -0600 Subject: [Rd] (PR#13288) Bug#505698: r-base-core: dev2bitmap fails with gsexe related error In-Reply-To: References: <20081114141504.8098C2834153@mail.pubhealth.ku.dk> Message-ID: <18717.37187.811555.628239@ron.nulle.part> On 14 November 2008 at 14:37, Prof Brian Ripley wrote: | >From the NEWS for R-patched | | o dev2bitmap() failed in 2.8.0 if 'taa' and 'gaa' were both NA. | | so this was already fixed. Thanks, will mark the bug as pending for Debian. Dirk -- Three out of two people have difficulties with fractions. From xieyihui at gmail.com Fri Nov 14 14:15:03 2008 From: xieyihui at gmail.com (xieyihui at gmail.com) Date: Fri, 14 Nov 2008 14:15:03 +0100 (CET) Subject: [Rd] Line breaks in mathematical formulae in Rd files (PR#13287) Message-ID: <20081114131503.B9F522834620@mail.pubhealth.ku.dk> Hi, This is a problem about writing R documentation (R-exts 2.6). The command "\deqn" defined in "Rd.sty" is: \newcommand{\deqn}[2]{\[#1\]} which will put mathematical formulae in the "displaymath" environment; that means line breaks are not allowed (or will not be shown) in formulae, but sometimes we do need multiple lines of formulae. One solution is to write several equations using "\deqn", but I think to change the definition of "\deqn" is better: \newcommand{\deqn}[2]{\begin{eqnarray*}#1\end{eqnarray*}} This will not change the pdfLaTeX output effect, moreover, line breaks and alignments using "&" will be available in math formulae. Regards, Yihui -- Yihui Xie Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086 Mobile: +86-15810805877 Homepage: http://www.yihui.name School of Statistics, Room 1037, Mingde Main Building, Renmin University of China, Beijing, 100872, China From ripley at stats.ox.ac.uk Fri Nov 14 17:29:52 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 16:29:52 +0000 (GMT) Subject: [Rd] (PR#13287) Line breaks in mathematical formulae in Rd files In-Reply-To: <20081114131503.B9F522834620@mail.pubhealth.ku.dk> References: <20081114131503.B9F522834620@mail.pubhealth.ku.dk> Message-ID: I think the 'problem' is a lack of attention to the manual. deqn gives ?displayed equations? (as in LaTeX's displaymath environment, or TeX's $$...$$). seems pretty clear to me, and I hope to any LaTeX user. On Fri, 14 Nov 2008, xieyihui at gmail.com wrote: > Hi, > > This is a problem about writing R documentation (R-exts 2.6). The > command "\deqn" defined in "Rd.sty" is: > > \newcommand{\deqn}[2]{\[#1\]} > > which will put mathematical formulae in the "displaymath" environment; Well, surprise, surprise it does what it is documented to do! > that means line breaks are not allowed (or will not be shown) in > formulae, but sometimes we do need multiple lines of formulae. One > solution is to write several equations using "\deqn", but I think to > change the definition of "\deqn" is better: > > \newcommand{\deqn}[2]{\begin{eqnarray*}#1\end{eqnarray*}} That will change the spacing. > This will not change the pdfLaTeX output effect, moreover, line breaks > and alignments using "&" will be available in math formulae. Not to the non-latex conversions. > Regards, > Yihui > -- > Yihui Xie > Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086 > Mobile: +86-15810805877 > Homepage: http://www.yihui.name > School of Statistics, Room 1037, Mingde Main Building, > Renmin University of China, Beijing, 100872, China > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From luke at stat.uiowa.edu Fri Nov 14 19:04:20 2008 From: luke at stat.uiowa.edu (Luke Tierney) Date: Fri, 14 Nov 2008 12:04:20 -0600 (CST) Subject: [Rd] error during list allocation In-Reply-To: <4919EDD4.5070009@idi.ntnu.no> References: <4919EDD4.5070009@idi.ntnu.no> Message-ID: Thanks for the report -- I was able to reproduce it on my systems by setting the process memory limit to a fairly low value (otherwise I just get into paging). The page allocation code should have done a GC after malloc failure and tried again; this is now fixed in R-devel and R-patched. luke On Tue, 11 Nov 2008, Wacek Kusnierczyk wrote: > platform i686-pc-linux-gnu > arch i686 > os linux-gnu > system i686, linux-gnu > status > major 2 > minor 8.0 > year 2008 > month 10 > day 20 > svn rev 46754 > language R > version.string R version 2.8.0 (2008-10-20) > > > when i try to allocate a large list, i get the following error: > > Error: vector memory exhausted (limit reached?) > > the process uses over 80% memory, and cannot be stopped from within r > (it responds to whatever input with the same message as above); i need > to kill the process to release resources. > > i think it would be practical to have the error reported *and* resources > freed when allocation fails. > the following should make a reproducible example: > > x = 1:(10^9) > # Error: cannot allocate vector of size 3.7 Gb > # no problem otherwise > > x = as.list(1:(10^8)) > # Error: vector memory exhausted (limit reached?) > quit() > # Error: vector memory exhausted (limit reached?) > 1 > # Error: vector memory exhausted (limit reached?) > > vQ > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke at stat.uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu From wdunlap at tibco.com Fri Nov 14 19:19:43 2008 From: wdunlap at tibco.com (William Dunlap) Date: Fri, 14 Nov 2008 10:19:43 -0800 Subject: [Rd] (PR#13283) R crashes on sprintf with bad format specification In-Reply-To: References: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk><491CBD6B.5000300@stats.uwo.ca> Message-ID: <77EB52C6DD32BA4D87471DCD70C8D70028E1AC@NA-PA-VBE03.na.tibco.com> > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Prof Brian Ripley > Sent: Friday, November 14, 2008 2:25 AM > To: Duncan Murdoch > Cc: R-bugs at r-project.org; ocheyett at bonddesk.com; > r-devel at stat.math.ethz.ch > Subject: Re: [Rd] (PR#13283) R crashes on sprintf with bad > format specification > > As R's sprintf is a wrapper for the OS's sprintf, misuse does > run the risk of crashing from OS, and when it does the error > will come from the implementation of sprintf (which for R for > Windows is the Trio library). > One could argue that the OS service should not segfault on > incorrect input, but this one often does. > > The place to add checks is in the R wrapper code (presumably > in the C component). We do have checks there, but it is hard > to imagine just what errors users will make, and this one has > slipped through the checks. The following change recognizes 'S' as a format type (but doesn't do anything with it) and thus avoids the crash. --- sprintf.c (revision 46944) +++ sprintf.c (working copy) @@ -103,7 +103,7 @@ else { /* recognise selected types from Table B-1 of K&R */ /* This is MBCS-OK, as we are in a format spec */ - chunk = strcspn(formatString + cur + 1, "aAdisfeEgGxX%") + 2; + chunk = strcspn(formatString + cur + 1, "aAdisSfeEgGxX%") + 2; if (cur + chunk > n) error(_("unrecognised format at end of string")); The resulting error messages are not terribly direct, but nicer than the crash > sprintf("A %S %S %S XYZ", 1, 1, 1) Error in sprintf("A %S %S %S XYZ", 1, 1, 1) : use format %f, %e, %g or %a for numeric objects > sprintf("A %S %S %S XYZ", "foo", "bar", "foo") Error in sprintf("A %S %S %S XYZ", "foo", "bar", "foo") : use format %s for character objects One could add 'S' to some switch cases below there to have it convert the corresponding argument to a wide character string or say directly that %S is not allowed. This piece of code finds the conversion type by looking for this first of a bunch of known conversion characters after the %, which doesn't find lots of illegal formats and causes some surprises. E.g., because 'p' is not in that list we get: > sprintf("%p", 3) Error in sprintf("%p", 3) : unrecognised format at end of string > sprintf("%p is a pointer!", 3) [1] "0x3 is a pointer!" > sprintf("%p %o", 17L, 17L) [1] "0x4 o" > Here the issue is the use of %S, an unknown format for > numbers, followed by 'X'. There is a check for a suitable > format, but it is not strict enough. And it is non-trivial > to write a printf format parser just to check for user error > (and potentially it will slow down correct uses: > speed in sprintf is important in some applications). > > So I am not sure this is something that should be R's > responsibility to > fix: maybe just add a warning to the help page? > > > On Thu, 13 Nov 2008, Duncan Murdoch wrote: > > > On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: > >> Full_Name: Oren Cheyette > >> Version: 2.7.2 > >> OS: Win XP > >> Submission from: (NULL) (64.161.123.194) > >> > >> > >> Enter the following at the R command prompt: > >>> sprintf("A %S %S %S XYZ", 1, 1, 1); > > R is not C, and the empty command at the end of that line (after the > semicolon) is not relevant. > > >> Note the erroneous capitalized %S instead of %s and the > numeric inputs > >> instead > >> of strings. With strings there's no crash - R reports bad format > >> specifications. > > > > 2.7.2 is obsolete, but I can confirm a crash on Windows > with a recent > > R-devel. > > > > The last few entries in the stack dump at the time of the > crash are shown > > below; these make it look as though the problem is in the > Trio library, so it > > may be hard to fix. > > > > Duncan Murdoch > > > > > > Rgui.exe caused an Access Violation at location 6c913fb3 in > module R.dll > > Reading from location 00000001. > > > > Registers: > > eax=7fffffff ebx=00000000 ecx=00e17b21 edx=00000001 > esi=00e1c83b edi=0000000a > > eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up > ei pl nz na po nc > > cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 > > > > Call stack: > > 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 > > > > ... > > while (length > 0) > > { > >> size = TrioWriteWideStringCharacter(self, > *wstring++, flags, > > length); > > if (size == 0) > > break; /* while */ > > ... > > > > 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 > > > > ... > > return status; > > > >> status = TrioFormatProcess(&data, format, parameters); > > if (data.error != 0) > > { > > ... > > > > 6C911F62 R.dll:6C911F62 sprintf compat.c:46 > > > > ... > > va_end(ap); > > return res; > >> } > > > > > > ... > > > > 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 > > > > ... > > sprintf(bit, fmtp, " NaN"); > > else > >> sprintf(bit, fmtp, "NaN"); > > } else if (x == R_PosInf) { > > if (strcspn(fmtp, "+") < strlen(fmtp)) > > ... > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Brian D. Ripley, ripley at stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From wdunlap at tibco.com Fri Nov 14 19:25:15 2008 From: wdunlap at tibco.com (wdunlap at tibco.com) Date: Fri, 14 Nov 2008 19:25:15 +0100 (CET) Subject: [Rd] (PR#13283) R crashes on sprintf with bad format specification Message-ID: <20081114182515.F0F1B2834156@mail.pubhealth.ku.dk> > From: r-devel-bounces at r-project.org=20 > [mailto:r-devel-bounces at r-project.org] On Behalf Of Prof Brian Ripley > Sent: Friday, November 14, 2008 2:25 AM > To: Duncan Murdoch > Cc: R-bugs at r-project.org; ocheyett at bonddesk.com;=20 > r-devel at stat.math.ethz.ch > Subject: Re: [Rd] (PR#13283) R crashes on sprintf with bad=20 > format specification >=20 > As R's sprintf is a wrapper for the OS's sprintf, misuse does=20 > run the risk of crashing from OS, and when it does the error=20 > will come from the implementation of sprintf (which for R for=20 > Windows is the Trio library). > One could argue that the OS service should not segfault on=20 > incorrect input, but this one often does. >=20 > The place to add checks is in the R wrapper code (presumably=20 > in the C component). We do have checks there, but it is hard=20 > to imagine just what errors users will make, and this one has=20 > slipped through the checks. The following change recognizes 'S' as a format type (but doesn't do anything with it) and thus avoids the crash. =20 --- sprintf.c (revision 46944) +++ sprintf.c (working copy) @@ -103,7 +103,7 @@ else { /* recognise selected types from Table B-1 of K&R */ /* This is MBCS-OK, as we are in a format spec */ - chunk =3D strcspn(formatString + cur + 1, "aAdisfeEgGxX%") + 2; + chunk =3D strcspn(formatString + cur + 1, "aAdisSfeEgGxX%") + 2; if (cur + chunk > n) error(_("unrecognised format at end of string")); The resulting error messages are not terribly direct, but nicer than the crash > sprintf("A %S %S %S XYZ", 1, 1, 1) Error in sprintf("A %S %S %S XYZ", 1, 1, 1) : use format %f, %e, %g or %a for numeric objects > sprintf("A %S %S %S XYZ", "foo", "bar", "foo") Error in sprintf("A %S %S %S XYZ", "foo", "bar", "foo") : use format %s for character objects One could add 'S' to some switch cases below there to have it convert the corresponding argument to a wide character string or say directly that %S is not allowed. This piece of code finds the conversion type by looking for this first of a bunch of known conversion characters after the %, which doesn't find lots of illegal formats and causes some surprises. E.g., because 'p' is not in that list we get: > sprintf("%p", 3) Error in sprintf("%p", 3) : unrecognised format at end of string > sprintf("%p is a pointer!", 3) [1] "0x3 is a pointer!" > sprintf("%p %o", 17L, 17L) [1] "0x4 o" > Here the issue is the use of %S, an unknown format for=20 > numbers, followed by 'X'. There is a check for a suitable=20 > format, but it is not strict enough. And it is non-trivial=20 > to write a printf format parser just to check for user error=20 > (and potentially it will slow down correct uses:=20 > speed in sprintf is important in some applications). >=20 > So I am not sure this is something that should be R's=20 > responsibility to > fix: maybe just add a warning to the help page? >=20 >=20 > On Thu, 13 Nov 2008, Duncan Murdoch wrote: >=20 > > On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: > >> Full_Name: Oren Cheyette > >> Version: 2.7.2 > >> OS: Win XP > >> Submission from: (NULL) (64.161.123.194) > >>=20 > >>=20 > >> Enter the following at the R command prompt: > >>> sprintf("A %S %S %S XYZ", 1, 1, 1); >=20 > R is not C, and the empty command at the end of that line (after the=20 > semicolon) is not relevant. >=20 > >> Note the erroneous capitalized %S instead of %s and the=20 > numeric inputs=20 > >> instead > >> of strings. With strings there's no crash - R reports bad format > >> specifications. > > > > 2.7.2 is obsolete, but I can confirm a crash on Windows=20 > with a recent=20 > > R-devel. > > > > The last few entries in the stack dump at the time of the=20 > crash are shown=20 > > below; these make it look as though the problem is in the=20 > Trio library, so it=20 > > may be hard to fix. > > > > Duncan Murdoch > > > > > > Rgui.exe caused an Access Violation at location 6c913fb3 in=20 > module R.dll=20 > > Reading from location 00000001. > > > > Registers: > > eax=3D7fffffff ebx=3D00000000 ecx=3D00e17b21 edx=3D00000001=20 > esi=3D00e1c83b edi=3D0000000a > > eip=3D6c913fb3 esp=3D00e17944 ebp=3D00e17b3c iopl=3D0 nv up=20 > ei pl nz na po nc > > cs=3D001b ss=3D0023 ds=3D0023 es=3D0023 fs=3D003b gs=3D0000 = efl=3D00000206 > > > > Call stack: > > 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 > > > > ... > > while (length > 0) > > { > >> size =3D TrioWriteWideStringCharacter(self,=20 > *wstring++, flags,=20 > > length); > > if (size =3D=3D 0) > > break; /* while */ > > ... > > > > 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 > > > > ... > > return status; > > > >> status =3D TrioFormatProcess(&data, format, parameters); > > if (data.error !=3D 0) > > { > > ... > > > > 6C911F62 R.dll:6C911F62 sprintf compat.c:46 > > > > ... > > va_end(ap); > > return res; > >> } > > > > > > ... > > > > 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 > > > > ... > > sprintf(bit, fmtp, " NaN"); > > else > >> sprintf(bit, fmtp, "NaN"); > > } else if (x =3D=3D R_PosInf) { > > if (strcspn(fmtp, "+") < strlen(fmtp)) > > ... > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > >=20 > --=20 > Brian D. Ripley, ripley at stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 >=20 > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >=20 From ripley at stats.ox.ac.uk Fri Nov 14 19:25:41 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 18:25:41 +0000 (GMT) Subject: [Rd] (PR#13283) R crashes on sprintf with bad format specification In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D70028E1AC@NA-PA-VBE03.na.tibco.com> References: <20081113013006.E82FF282EFF6@mail.pubhealth.ku.dk><491CBD6B.5000300@stats.uwo.ca> <77EB52C6DD32BA4D87471DCD70C8D70028E1AC@NA-PA-VBE03.na.tibco.com> Message-ID: But %S is not valid in C99 or POSIX, even if it is a variant in some systems. I am working on a more careful checker right now, but there will be limits to what we can catch: this was already a pretty rare example. Brian On Fri, 14 Nov 2008, William Dunlap wrote: >> From: r-devel-bounces at r-project.org >> [mailto:r-devel-bounces at r-project.org] On Behalf Of Prof Brian Ripley >> Sent: Friday, November 14, 2008 2:25 AM >> To: Duncan Murdoch >> Cc: R-bugs at r-project.org; ocheyett at bonddesk.com; >> r-devel at stat.math.ethz.ch >> Subject: Re: [Rd] (PR#13283) R crashes on sprintf with bad >> format specification >> >> As R's sprintf is a wrapper for the OS's sprintf, misuse does >> run the risk of crashing from OS, and when it does the error >> will come from the implementation of sprintf (which for R for >> Windows is the Trio library). >> One could argue that the OS service should not segfault on >> incorrect input, but this one often does. >> >> The place to add checks is in the R wrapper code (presumably >> in the C component). We do have checks there, but it is hard >> to imagine just what errors users will make, and this one has >> slipped through the checks. > > The following change recognizes 'S' as a format type (but doesn't > do anything with it) and thus avoids the crash. > > --- sprintf.c (revision 46944) > +++ sprintf.c (working copy) > @@ -103,7 +103,7 @@ > else { > /* recognise selected types from Table B-1 of K&R */ > /* This is MBCS-OK, as we are in a format spec */ > - chunk = strcspn(formatString + cur + 1, > "aAdisfeEgGxX%") + 2; > + chunk = strcspn(formatString + cur + 1, > "aAdisSfeEgGxX%") + 2; > if (cur + chunk > n) > error(_("unrecognised format at end of > string")); > > The resulting error messages are not terribly direct, but nicer > than the crash > > sprintf("A %S %S %S XYZ", 1, 1, 1) > Error in sprintf("A %S %S %S XYZ", 1, 1, 1) : > use format %f, %e, %g or %a for numeric objects > > sprintf("A %S %S %S XYZ", "foo", "bar", "foo") > Error in sprintf("A %S %S %S XYZ", "foo", "bar", "foo") : > use format %s for character objects > > One could add 'S' to some switch cases below there to have > it convert the corresponding argument to a wide character string > or say directly that %S is not allowed. > > This piece of code finds the conversion type by looking for this > first of a bunch of known conversion characters after the %, which > doesn't find lots of illegal formats and causes some surprises. E.g., > because 'p' is not in that list we get: > > sprintf("%p", 3) > Error in sprintf("%p", 3) : unrecognised format at end of string > > sprintf("%p is a pointer!", 3) > [1] "0x3 is a pointer!" > > sprintf("%p %o", 17L, 17L) > [1] "0x4 o" > >> Here the issue is the use of %S, an unknown format for >> numbers, followed by 'X'. There is a check for a suitable >> format, but it is not strict enough. And it is non-trivial >> to write a printf format parser just to check for user error >> (and potentially it will slow down correct uses: >> speed in sprintf is important in some applications). >> >> So I am not sure this is something that should be R's >> responsibility to >> fix: maybe just add a warning to the help page? >> >> >> On Thu, 13 Nov 2008, Duncan Murdoch wrote: >> >>> On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: >>>> Full_Name: Oren Cheyette >>>> Version: 2.7.2 >>>> OS: Win XP >>>> Submission from: (NULL) (64.161.123.194) >>>> >>>> >>>> Enter the following at the R command prompt: >>>>> sprintf("A %S %S %S XYZ", 1, 1, 1); >> >> R is not C, and the empty command at the end of that line (after the >> semicolon) is not relevant. >> >>>> Note the erroneous capitalized %S instead of %s and the >> numeric inputs >>>> instead >>>> of strings. With strings there's no crash - R reports bad format >>>> specifications. >>> >>> 2.7.2 is obsolete, but I can confirm a crash on Windows >> with a recent >>> R-devel. >>> >>> The last few entries in the stack dump at the time of the >> crash are shown >>> below; these make it look as though the problem is in the >> Trio library, so it >>> may be hard to fix. >>> >>> Duncan Murdoch >>> >>> >>> Rgui.exe caused an Access Violation at location 6c913fb3 in >> module R.dll >>> Reading from location 00000001. >>> >>> Registers: >>> eax=7fffffff ebx=00000000 ecx=00e17b21 edx=00000001 >> esi=00e1c83b edi=0000000a >>> eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up >> ei pl nz na po nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 >>> >>> Call stack: >>> 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 >>> >>> ... >>> while (length > 0) >>> { >>>> size = TrioWriteWideStringCharacter(self, >> *wstring++, flags, >>> length); >>> if (size == 0) >>> break; /* while */ >>> ... >>> >>> 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 >>> >>> ... >>> return status; >>> >>>> status = TrioFormatProcess(&data, format, parameters); >>> if (data.error != 0) >>> { >>> ... >>> >>> 6C911F62 R.dll:6C911F62 sprintf compat.c:46 >>> >>> ... >>> va_end(ap); >>> return res; >>>> } >>> >>> >>> ... >>> >>> 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 >>> >>> ... >>> sprintf(bit, fmtp, " NaN"); >>> else >>>> sprintf(bit, fmtp, "NaN"); >>> } else if (x == R_PosInf) { >>> if (strcspn(fmtp, "+") < strlen(fmtp)) >>> ... >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> -- >> Brian D. Ripley, ripley at stats.ox.ac.uk >> 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, UK Fax: +44 1865 272595 >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Fri Nov 14 19:30:09 2008 From: ripley at stats.ox.ac.uk (ripley at stats.ox.ac.uk) Date: Fri, 14 Nov 2008 19:30:09 +0100 (CET) Subject: [Rd] (PR#13283) R crashes on sprintf with bad format Message-ID: <20081114183009.7084D2834156@mail.pubhealth.ku.dk> But %S is not valid in C99 or POSIX, even if it is a variant in some systems. I am working on a more careful checker right now, but there will be limits to what we can catch: this was already a pretty rare example. Brian On Fri, 14 Nov 2008, William Dunlap wrote: >> From: r-devel-bounces at r-project.org >> [mailto:r-devel-bounces at r-project.org] On Behalf Of Prof Brian Ripley >> Sent: Friday, November 14, 2008 2:25 AM >> To: Duncan Murdoch >> Cc: R-bugs at r-project.org; ocheyett at bonddesk.com; >> r-devel at stat.math.ethz.ch >> Subject: Re: [Rd] (PR#13283) R crashes on sprintf with bad >> format specification >> >> As R's sprintf is a wrapper for the OS's sprintf, misuse does >> run the risk of crashing from OS, and when it does the error >> will come from the implementation of sprintf (which for R for >> Windows is the Trio library). >> One could argue that the OS service should not segfault on >> incorrect input, but this one often does. >> >> The place to add checks is in the R wrapper code (presumably >> in the C component). We do have checks there, but it is hard >> to imagine just what errors users will make, and this one has >> slipped through the checks. > > The following change recognizes 'S' as a format type (but doesn't > do anything with it) and thus avoids the crash. > > --- sprintf.c (revision 46944) > +++ sprintf.c (working copy) > @@ -103,7 +103,7 @@ > else { > /* recognise selected types from Table B-1 of K&R */ > /* This is MBCS-OK, as we are in a format spec */ > - chunk = strcspn(formatString + cur + 1, > "aAdisfeEgGxX%") + 2; > + chunk = strcspn(formatString + cur + 1, > "aAdisSfeEgGxX%") + 2; > if (cur + chunk > n) > error(_("unrecognised format at end of > string")); > > The resulting error messages are not terribly direct, but nicer > than the crash > > sprintf("A %S %S %S XYZ", 1, 1, 1) > Error in sprintf("A %S %S %S XYZ", 1, 1, 1) : > use format %f, %e, %g or %a for numeric objects > > sprintf("A %S %S %S XYZ", "foo", "bar", "foo") > Error in sprintf("A %S %S %S XYZ", "foo", "bar", "foo") : > use format %s for character objects > > One could add 'S' to some switch cases below there to have > it convert the corresponding argument to a wide character string > or say directly that %S is not allowed. > > This piece of code finds the conversion type by looking for this > first of a bunch of known conversion characters after the %, which > doesn't find lots of illegal formats and causes some surprises. E.g., > because 'p' is not in that list we get: > > sprintf("%p", 3) > Error in sprintf("%p", 3) : unrecognised format at end of string > > sprintf("%p is a pointer!", 3) > [1] "0x3 is a pointer!" > > sprintf("%p %o", 17L, 17L) > [1] "0x4 o" > >> Here the issue is the use of %S, an unknown format for >> numbers, followed by 'X'. There is a check for a suitable >> format, but it is not strict enough. And it is non-trivial >> to write a printf format parser just to check for user error >> (and potentially it will slow down correct uses: >> speed in sprintf is important in some applications). >> >> So I am not sure this is something that should be R's >> responsibility to >> fix: maybe just add a warning to the help page? >> >> >> On Thu, 13 Nov 2008, Duncan Murdoch wrote: >> >>> On 12/11/2008 8:30 PM, ocheyett at bonddesk.com wrote: >>>> Full_Name: Oren Cheyette >>>> Version: 2.7.2 >>>> OS: Win XP >>>> Submission from: (NULL) (64.161.123.194) >>>> >>>> >>>> Enter the following at the R command prompt: >>>>> sprintf("A %S %S %S XYZ", 1, 1, 1); >> >> R is not C, and the empty command at the end of that line (after the >> semicolon) is not relevant. >> >>>> Note the erroneous capitalized %S instead of %s and the >> numeric inputs >>>> instead >>>> of strings. With strings there's no crash - R reports bad format >>>> specifications. >>> >>> 2.7.2 is obsolete, but I can confirm a crash on Windows >> with a recent >>> R-devel. >>> >>> The last few entries in the stack dump at the time of the >> crash are shown >>> below; these make it look as though the problem is in the >> Trio library, so it >>> may be hard to fix. >>> >>> Duncan Murdoch >>> >>> >>> Rgui.exe caused an Access Violation at location 6c913fb3 in >> module R.dll >>> Reading from location 00000001. >>> >>> Registers: >>> eax=7fffffff ebx=00000000 ecx=00e17b21 edx=00000001 >> esi=00e1c83b edi=0000000a >>> eip=6c913fb3 esp=00e17944 ebp=00e17b3c iopl=0 nv up >> ei pl nz na po nc >>> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206 >>> >>> Call stack: >>> 6C913FB3 R.dll:6C913FB3 TrioFormatProcess trio.c:2724 >>> >>> ... >>> while (length > 0) >>> { >>>> size = TrioWriteWideStringCharacter(self, >> *wstring++, flags, >>> length); >>> if (size == 0) >>> break; /* while */ >>> ... >>> >>> 6C916592 R.dll:6C916592 trio_vsprintf trio.c:3771 >>> >>> ... >>> return status; >>> >>>> status = TrioFormatProcess(&data, format, parameters); >>> if (data.error != 0) >>> { >>> ... >>> >>> 6C911F62 R.dll:6C911F62 sprintf compat.c:46 >>> >>> ... >>> va_end(ap); >>> return res; >>>> } >>> >>> >>> ... >>> >>> 6C889F1E R.dll:6C889F1E do_sprintf sprintf.c:297 >>> >>> ... >>> sprintf(bit, fmtp, " NaN"); >>> else >>>> sprintf(bit, fmtp, "NaN"); >>> } else if (x == R_PosInf) { >>> if (strcspn(fmtp, "+") < strlen(fmtp)) >>> ... >>> >>> ______________________________________________ >>> R-devel at r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >>> >> >> -- >> Brian D. Ripley, ripley at stats.ox.ac.uk >> 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, UK Fax: +44 1865 272595 >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From lgautier at gmail.com Fri Nov 14 20:23:34 2008 From: lgautier at gmail.com (laurent) Date: Fri, 14 Nov 2008 20:23:34 +0100 Subject: [Rd] problem with postscript/pdf plots, locales and embedded R Message-ID: <1226690614.8615.26.camel@hot-spring> Dear list, A problem with creating pdf or postscript plots from an embedded R, and in an environment where a locale is defined, was recently reported on the rpy (Python->R interface) mailing list. The problem appears to be that whenever the locale defines ',' as a separator for the decimal part of a numerical value, the pdf/ps file generated still has the ',' instead of a '.' causing problem when open the resulting file with a postscript/pdf viewer. Of course, an obvious workaround would be to force the locale for numbers to C ( LC_NUMERIC = "C" ), but that could be overriding internationalization features otherwise in R. Any advice ? Thanks, Laurent From ripley at stats.ox.ac.uk Fri Nov 14 20:37:55 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 14 Nov 2008 19:37:55 +0000 (GMT) Subject: [Rd] problem with postscript/pdf plots, locales and embedded R In-Reply-To: <1226690614.8615.26.camel@hot-spring> References: <1226690614.8615.26.camel@hot-spring> Message-ID: On Fri, 14 Nov 2008, laurent wrote: > Dear list, > > A problem with creating pdf or postscript plots from an embedded R, and > in an environment where a locale is defined, was recently reported on > the rpy (Python->R interface) mailing list. > > The problem appears to be that whenever the locale defines ',' as a > separator for the decimal part of a numerical value, the pdf/ps file > generated still has the ',' instead of a '.' causing problem when open > the resulting file with a postscript/pdf viewer. > > Of course, an obvious workaround would be to force the locale for > numbers to C ( LC_NUMERIC = "C" ), but that could be overriding > internationalization features otherwise in R. > > Any advice ? Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that. It used to cause far more problems than this. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From shntn05 at gmail.com Fri Nov 14 23:53:25 2008 From: shntn05 at gmail.com (Shantanu D) Date: Fri, 14 Nov 2008 16:53:25 -0600 Subject: [Rd] problem in downloading the rimage package Message-ID: <4e835e290811141453y5cf0016dp91cc99c8fb45a144@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From shntn05 at gmail.com Sat Nov 15 00:34:49 2008 From: shntn05 at gmail.com (Shantanu D) Date: Fri, 14 Nov 2008 17:34:49 -0600 Subject: [Rd] Problem trying to download rimage package (second try) Message-ID: <4e835e290811141534m62852d14i6adf29e229f7a108@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From jeff.a.ryan at gmail.com Sat Nov 15 01:35:17 2008 From: jeff.a.ryan at gmail.com (Jeff Ryan) Date: Fri, 14 Nov 2008 18:35:17 -0600 Subject: [Rd] Problem trying to download rimage package (second try) In-Reply-To: <4e835e290811141534m62852d14i6adf29e229f7a108@mail.gmail.com> References: <4e835e290811141534m62852d14i6adf29e229f7a108@mail.gmail.com> Message-ID: You are receiving no reply to your request as you are asking a list for R package and core developers about a single package (1 of 1600+ on CRAN alone). 1) You should first try everything possible yourself to fix the problem, AND show your work... (as per posting rules) 2) Then contact the maintainer (as per posting rules). 3) Then ask R-help (not R-devel), and only then (if ever) as a last resort come here for general install questions. The package description to get you to step #2: http://cran.r-project.org/web/packages/rimage/index.html Jeff On Fri, Nov 14, 2008 at 5:34 PM, Shantanu D wrote: > Hi, > There seems to have been some problem with posting my earlier message and am > providing a link to the problem I faced which is at > https://stat.ethz.ch/pipermail/r-devel/attachments/20081114/84972faf/attachment.pl > Any help would be appreciated as I need to use this package urgently and > also tried various other things without luck > Thanks > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Jeffrey Ryan jeffrey.ryan at insightalgo.com ia: insight algorithmics www.insightalgo.com From tplate at acm.org Sat Nov 15 02:01:08 2008 From: tplate at acm.org (Tony Plate) Date: Fri, 14 Nov 2008 18:01:08 -0700 Subject: [Rd] Package install problem on Windows (PR#13284) In-Reply-To: <18717.15219.178923.14858@stat.math.ethz.ch> References: <20081113033503.20E60282EFC1@mail.pubhealth.ku.dk> <491CB41F.503@acm.org> <18717.15219.178923.14858@stat.math.ethz.ch> Message-ID: <491E1F54.10809@acm.org> Thanks to Prof Brian Ripley, Martin Maechler, and Simon Urbanek for the very informative responses. It's good to learn that there is a chance that versioned installs will go away -- we will avoid using them. It's also useful to hear of how others create stable package libraries while making continual development possible by using different library paths, and by dynamically manipulating library paths. It makes sense for us to take a similar approach. I guess one could take the multiple-library-path approach to the extreme of having a single package in each library, with a library for each version, e.g., a version 3.1 of package called xyz could be installed in library called "xyz_3.1" (so the path of the package would be .../xyz_3.1/xyz, and then one would make a call like library("xyz", lib.loc=".../xyz_3.1") to get this version.) This approach could also provide a solution to the challenge (under Windows) of installing a new version of package into a library without disturbing running R sessions that might have that package attached -- by creating a new library for the newly installed package, and dynamically finding the latest library prior to attaching packages at the beginning of a session. Are there any potential pitfalls to this approach that we should know about? -- Tony Plate Martin Maechler wrote: >>>>>> "SU" == Simon Urbanek >>>>>> on Thu, 13 Nov 2008 18:47:38 -0500 writes: >>>>>> > > SU> On Nov 13, 2008, at 6:11 PM, Tony Plate wrote: > > >> Thanks for the response. > >> > >> Are the problems with versioned installs fundamental, or > >> are they just a case of incomplete implementation and > >> rough edges? If the latter, would fixes be considered? > >> > >> I ask because we would find versioned installs very > >> useful in maintaining stable production systems, each of > >> which might run with different versions of various > >> packages, while making it easy to continually develop and > >> refine our packages. As a point of info, our primary use > >> for versioning would be with our own packages, so we > >> could probably get away without using versioned installs > >> for base or contributed packages. > >> > > SU> I find it more useful to work with multiple library paths > SU> (.libPaths()) than versioning packages in the above > SU> scenario. We usually maintain "stable" package library > SU> which is individually overridden by additional paths > SU> added by the user (e.g. developer library for testing) > SU> and/or subsystems. The override can also be revertive, > SU> i.e. a subsystem is free to use older packages in its > SU> library than the stable library when desired. > > We use the same "technique", > both using the R_LIBS environment variable, and also amending it > in an .Rprofile equivalent depending on the version of R (or the > user), i.e., something like > > libPIns <- function(nlib, beforeLib, msgTxt) { > ## Purpose: Insert a directory into .libPaths() *before* another one > ## ---------------------------------------------------------------- > ## Arguments: nlib: The library directory to insert > ## beforeLib: (grep-pattern of an) entry in current .libPaths() > ## msgTxt: optional message text about the insertion > ## ---------------------------------------------------------------- > ## Author: Martin Maechler, 2006 > > if(file.exists(nlib)) { > if(length({fl <- list.files(nlib); fl[fl != "R.css"]})) { > ## only if the library contains any packages : > if(!missing(msgTxt) && is.character(msgTxt)) > cat("extending .libPaths()", msgTxt,"...\n") > ni <- length(iL <- grep(beforeLib, lp <- .libPaths())) > if(ni != 1) { > warning(".libPaths() contains ", > if(ni>1) "more" else "no", > " entries matching ",sQuote(beforeLib)) > iL <- if(ni > 1) iL[1] else length(lp) > cat("Inserting before position", iL,"..\n") > } > ii <- 1:length(lp) > .libPaths(c(lp[ii < iL], nlib, lp[ii >= iL])) > } > } else warning(nlib, " is not an existing directory") > } > > and then somewhere > > > RVersion <- paste(R.version$major, R.version$minor, sep=".") > Rstat <- R.version$status > is.Rdevel <- ## Rstat == "beta" || > length(grep("devel", Rstat)) > 0 > if(is.Rdevel) > libPIns(nlib = file.path(RrootDir,"library-R-devel"), > beforeLib = file.path(RrootDir,"library"), > msgTxt = "for 'R-devel'") > and other such > > if(.....) > libPIns(....) > > calls. > > Martin Maechler, ETH Zurich > > > > > > > >> However, if the problems with versioned installs are not > >> amenable to the kinds of fixes that users can contribute, > >> then I guess we should look for a different approach. > >> > >> Suggestions and comments are welcome! Do many people use > >> versioned installs? > >> > >> -- Tony Plate (coworker of Lars @ blackmesacapital.com) > >> > >> Prof Brian Ripley wrote: > >>> Installing versioned packages is not supported with > >>> namespaces. I have suggested from time to time that > >>> versioned installs be removed because of this and other > >>> known issues, and recommend that you do not attempt to > >>> use them. > >>> > >>> On Thu, 13 Nov 2008, lhansen at blackmesacapital.com wrote: > >>> > >>>> Full_Name: Lars Hansen Version: 2.8.0 OS: Windows XP > >>>> Pro x64 SP2 Submission from: (NULL) (71.39.177.36) > >>>> > >>>> > >>>> Hi, > >>>> > >>>> I have run into a problem using "R CMD INSTALL" with > >>>> the "--with-package-versions" option under Windows. It > >>>> is a bit obscure, which could explain why other people > >>>> have not run into it. > >>>> > >>>> We happen to have two packages with almost the same > >>>> name. One name is a subset of the other. The names are > >>>> "RtTests" and "RtTestsEG1". I have no problem > >>>> installing "RtTests" and many other packages, but run > >>>> into problems installing "RtTestsEG1". The "RtTestsEG1" > >>>> package happens to be a simple example of how to use > >>>> the "RtTests" package, so it depends on "RtTests" > >>>> (which is probably the problem). > >>>> > >>>> OK, so this is what happens when I attempt to install > >>>> "RtTestsEG1": > >>>> > >>>> $ R CMD INSTALL --with-package-versions > >>>> --library=$R_LIBS RtTestsEG1 > >>>> > >>>> installing RtTestsEG1 package > >>>> > >>>> ---------- Making package RtTestsEG1 ------------ > >>>> adding build stamp to DESCRIPTION installing R files > >>>> preparing package RtTestsEG1 for lazy loading Loading > >>>> required package: RtTests ... [lost of lines removed] > >>>> Loading required package: RtTests Error: evaluation > >>>> nested too deeply: infinite recursion / > >>>> options(expressions=)? Execution halted make[2]: *** > >>>> [lazyload] Error 1 make[1]: *** [all] Error 2 make: *** > >>>> [pkg-RtTestsEG1] Error 2 *** Installation of RtTestsEG1 > >>>> failed *** > >>>> > >>>> After some digging in the Windows makefiles, I found > >>>> out that changing the locale from "C" to "us" in the > >>>> "lazyload" target of $R_HOME/src/gnuwin32/MakePkg, > >>>> i.e. using "LC_ALL=us" instead of "LC_ALL=C", solves > >>>> the infinite recursion problem and give an useful > >>>> message. It still fails but now says: > >>>> > >>>> Loading required package: RtTests Warning: S3 methods > >>>> 'summary.RtTestSetResults', 'print.RtTestSetResults', > >>>> 'print.RtTestSetResults.summary' were declared in > >>>> NAMESPACE but not found Error in namespaceExport(ns, > >>>> exports) : undefined exports: parseTranscriptFile, > >>>> compareTranscriptAndOutput Error: package 'RtTests' > >>>> could not be loaded Execution halted > >>>> > >>>> It is true that RtTests declares the various functions > >>>> in its name space, but why can they suddenly not be > >>>> found? If I load RtTests by itself, i.e. > >>>> library(RtTests), there is no problem. > >>>> > >>>> I happen to have all this working under Linux, so I > >>>> tracked down the difference. Turns out that under > >>>> Linux the equivalent to the "lazyload" target is in > >>>> "/usr/lib/R/bin/INSTALL" and the difference is in the > >>>> argument passed to "tools:::makeLazyLoading". Under > >>>> Linux the full package name with version number is > >>>> used, i.e. "RtTests_0.1-1". Windows just uses > >>>> "RtTests". > >>>> > >>>> So I managed to fix the problem by making Windows use > >>>> the full package name in the "lazyload" target. I > >>>> replaced tools:::makeLazyLoading(\"$(PKG)\" with > >>>> tools:::makeLazyLoading(\"$(notdir $(DPKG))\" > >>>> > >>>> If I now reinstall "RtTests", I can finally install > >>>> "RtTestsEG1". > >>>> > >>>> I must confess, that I do not fully understand exactly > >>>> what it takes to reproduce this problem. I am guessing > >>>> that all it takes is a package depending on a versioned > >>>> package. Maybe the similarity in names introduces a > >>>> problem because of partial matching. I am guessing that > >>>> has nothing to do with it. > >>>> > >>>> To sum up the report. I see two problems: > >>>> > >>>> 1) LC_ALL=C causes infinite recursion. It is as if the > >>>> C locale does not work under Windows. I do not know > >>>> what the fix is. It is used many places in install > >>>> scripts and makefiles. Fixing it in the "lazyload" > >>>> target is not enough. Even with my change I still get > >>>> "infinite recursion" and no error message if I try to > >>>> install "RtTestsEG1" without first installing > >>>> "RtTests". > >>>> > >>>> 2) "makeLazyLoading()" in "lazyload" target needs to be > >>>> called with full package name with embedded version > >>>> number. I think this is bug under Windows and my fix > >>>> takes care of it. > >>>> > >>>> It took some time to figure this out. I am hoping this > >>>> report will save other people time. I am note sure if I > >>>> succeeded in describing the problem clearly. Please do > >>>> not hesitate to ask for clarification. > >>>> > >>>> Thanks, Lars Hansen > >>>> > >>>> P.S. > >>>>> sessionInfo() > >>>> R version 2.8.0 Patched (2008-10-22 r46776) > >>>> i386-pc-mingw32 > >>>> > >>>> locale: LC_COLLATE=English_United > >>>> States.1252;LC_CTYPE=English_United > >>>> States.1252;LC_MONETARY=English_United > >>>> States.1252;LC_NUMERIC=C;LC_TIME=English_United > >>>> States.1252 > >>>> > >>>> attached base packages: [1] stats graphics grDevices > >>>> utils datasets methods base > >>>> > >>>> ______________________________________________ > >>>> R-devel at r-project.org mailing list > >>>> https://stat.ethz.ch/mailman/listinfo/r-devel > >>>> > >>> > >> ______________________________________________ >> > >> R-devel at r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > >> > >> > > ______________________________________________ > SU> R-devel at r-project.org mailing list > SU> https://stat.ethz.ch/mailman/listinfo/r-devel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From simon.urbanek at r-project.org Sat Nov 15 02:33:45 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Fri, 14 Nov 2008 20:33:45 -0500 Subject: [Rd] problem in downloading the rimage package In-Reply-To: <4e835e290811141453y5cf0016dp91cc99c8fb45a144@mail.gmail.com> References: <4e835e290811141453y5cf0016dp91cc99c8fb45a144@mail.gmail.com> Message-ID: <105E6D54-5234-4A46-8360-2CA48821D1D2@r-project.org> On Nov 14, 2008, at 5:53 PM, Shantanu D wrote: > I am using a 64 bit machine with CentOS5. I am getting the following > errors > when I try to install the rimage package > > g++ -shared -L/usr/local/lib64 -o rimage.so equalize.o > fftw_access_func.o > freqfilters.o interface.o jpegio.o laplacian.o matrix.o smooth.o > sobel.o > -ljpeg -lfftw > /usr/bin/ld: /usr/local/lib/libfftw.a(fftwnd.o): relocation > R_X86_64_32 > against `a local symbol' can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/libfftw.a: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [rimage.so] Error 1 > chmod: cannot access `/home/shantanu/R/rimage/libs/*': No such file or > directory > ERROR: compilation failed for package 'rimage' > > > Any help would be appreciated. Could not find anything with google > search. > It helps to read the error, because that tells you all you need to know - you have to recompile libfftw with -fPIC (or use dynamic library instead of static one). Cheers, S From ripley at stats.ox.ac.uk Sat Nov 15 03:18:33 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Sat, 15 Nov 2008 02:18:33 +0000 (GMT) Subject: [Rd] problem in downloading the rimage package In-Reply-To: <4e835e290811141453y5cf0016dp91cc99c8fb45a144@mail.gmail.com> References: <4e835e290811141453y5cf0016dp91cc99c8fb45a144@mail.gmail.com> Message-ID: On Fri, 14 Nov 2008, Shantanu D wrote: > I am using a 64 bit machine with CentOS5. I am getting the following errors > when I try to install the rimage package > > g++ -shared -L/usr/local/lib64 -o rimage.so equalize.o fftw_access_func.o > freqfilters.o interface.o jpegio.o laplacian.o matrix.o smooth.o sobel.o > -ljpeg -lfftw > /usr/bin/ld: /usr/local/lib/libfftw.a(fftwnd.o): relocation R_X86_64_32 > against `a local symbol' can not be used when making a shared object; > recompile with -fPIC > /usr/local/lib/libfftw.a: could not read symbols: Bad value /usr/local/lib/libfftw.a: is where a 32-bit static library is placed. This looks like a 64-bit system, in which case you need a dynamic library, /usr/local/lib64/libfftw.so. This is nothing to do with your subject line (what did 'downloading' have to do with this?), but reflects a problem with a local software install on your machine. Only you can explain how fftw2 got installed as it did. > collect2: ld returned 1 exit status > make: *** [rimage.so] Error 1 > chmod: cannot access `/home/shantanu/R/rimage/libs/*': No such file or > directory > ERROR: compilation failed for package 'rimage' > > > Any help would be appreciated. Could not find anything with google search. > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From lgautier at gmail.com Sat Nov 15 18:49:49 2008 From: lgautier at gmail.com (laurent) Date: Sat, 15 Nov 2008 18:49:49 +0100 Subject: [Rd] problem with postscript/pdf plots, locales and embedded R In-Reply-To: References: <1226690614.8615.26.camel@hot-spring> Message-ID: <1226771389.23719.14.camel@hot-spring> Thanks for the quick answer. The documentation for Sys.setlocale mentions the possibility of warning when LC_NUMERIC is set. After checking it is looking like setting LC_NUMERIC from Sys.setlocale does issue a warning, but there is does not seem to be a warning when LC_NUMERIC is set in the parent shell. In the case the later is likely to cause trouble, would it be appropriate to issue a warning when R is initialized ? Laurent On Fri, 2008-11-14 at 19:37 +0000, Prof Brian Ripley wrote: > On Fri, 14 Nov 2008, laurent wrote: > > > Dear list, > > > > A problem with creating pdf or postscript plots from an embedded R, and > > in an environment where a locale is defined, was recently reported on > > the rpy (Python->R interface) mailing list. > > > > The problem appears to be that whenever the locale defines ',' as a > > separator for the decimal part of a numerical value, the pdf/ps file > > generated still has the ',' instead of a '.' causing problem when open > > the resulting file with a postscript/pdf viewer. > > > > Of course, an obvious workaround would be to force the locale for > > numbers to C ( LC_NUMERIC = "C" ), but that could be overriding > > internationalization features otherwise in R. > > > > Any advice ? > > Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that. > It used to cause far more problems than this. > From deepayan.sarkar at gmail.com Sun Nov 16 10:26:18 2008 From: deepayan.sarkar at gmail.com (Deepayan Sarkar) Date: Sun, 16 Nov 2008 01:26:18 -0800 Subject: [Rd] Fw: alpha transparency crashes R Message-ID: I'm forwarding a bug report from Jeff Gove that didn't make it to the list. -Deepayan ------- Original Message -------- Subject: alpha transparency crashes R Date: Fri, 07 Nov 2008 14:32:27 -0500 From: jeff gove To: r-bugs at r-project.org I ran into a problem with R crashing when a certain number of transparent objects (e.g., symbols) are sent to a PDF output device. This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04 platforms) and now 2.8.0 (I've only tried Fedora 8). The current pertinent R system stats are... R.version _ platform x86_64-redhat-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status major 2 minor 8.0 year 2008 month 10 day 20 svn rev 46754 language R version.string R version 2.8.0 (2008-10-20) The following small example program when run with n large enough (e.g., n=1000) and transparency will crash R... alphaBomb.r = function(n=100, wantAlpha=T) { df = data.frame(a=rnorm(n),b=runif(n)) if(wantAlpha) alpha=runif(n) else alpha = 1 j = xyplot(b~a, df, alpha=alpha, pch=19) print(j) trellis.device('pdf',file='alphaBomb.pdf',version='1.4') print(j) dev.off() } Please note that the crash seems to occur in the dev.off() component, and that the file actually seems to get written out correctly. The trace of the bomb is found below, excluding the memory map. Please also note that it may be somehow related to grid, as the following code (supplied by Deepayan Sarkar) using base graphics does not crash R, even with n=100000... pdf() n = 1000 plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16) dev.off() The error trace from the above alphaBomb.r() code is... R> alphaBomb.r(100) #this is fine X11cairo 2 R> alphaBomb.r(1000,F) #also fine R> alphaBomb.r(1000) *** glibc detected *** /usr/lib64/R/bin/exec/R: double free or corruption (!prev): 0x00000000032c1d90 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3ee8c72832] /lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c] /usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc] /usr/lib64/R/lib/libR.so[0x3d1f48ddd3] /usr/lib64/R/lib/libR.so[0x3d1f48e2dc] /usr/lib64/R/lib/libR.so[0x3d1f4ec81c] /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] /usr/lib64/R/lib/libR.so[0x3d1f4bf572] /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1] /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783] /usr/lib64/R/lib/libR.so[0x3d1f4bf572] /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1] /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783] /usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878] /usr/lib64/R/lib/libR.so[0x3d1f4dcb90] /usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0] /usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074] /usr/lib64/R/bin/exec/R[0x400729] ======= Memory map: ======== etc... Please note that R only crashes with PDF output; tiff, png and eps (even though it doesn't accept transparency) all exit cleanly. My version of glibc is 2.7. Thanks, I hope that the problem is already resolved! Jeff From ripley at stats.ox.ac.uk Sun Nov 16 13:40:05 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Sun, 16 Nov 2008 12:40:05 +0000 (GMT) Subject: [Rd] problem with postscript/pdf plots, locales and embedded R In-Reply-To: <1226771389.23719.14.camel@hot-spring> References: <1226690614.8615.26.camel@hot-spring> <1226771389.23719.14.camel@hot-spring> Message-ID: You start from a false premise, and it seems that you are reporting a serious bug in Rpy to the wrong list: Note that R expects to be run with the locale category `LC_NUMERIC' set to its default value of C, and so should not be embedded into an application which changes that. ('Writing R Extensions'). On Sat, 15 Nov 2008, laurent wrote: > Thanks for the quick answer. > > The documentation for Sys.setlocale mentions the possibility of warning > when LC_NUMERIC is set. > > After checking it is looking like setting LC_NUMERIC from Sys.setlocale > does issue a warning, but there is does not seem to be a warning when > LC_NUMERIC is set in the parent shell. In the case the later is likely > to cause trouble, would it be appropriate to issue a warning when R is > initialized ? Of course R does not violate its own documentation. None of the R executables reset the LC_NUMERIC locale category, and all C programs start in the 'C' locale (both facts you should have known from the homework you did before posting). BDR > > > Laurent > > > > On Fri, 2008-11-14 at 19:37 +0000, Prof Brian Ripley wrote: >> On Fri, 14 Nov 2008, laurent wrote: >> >>> Dear list, >>> >>> A problem with creating pdf or postscript plots from an embedded R, and >>> in an environment where a locale is defined, was recently reported on >>> the rpy (Python->R interface) mailing list. >>> >>> The problem appears to be that whenever the locale defines ',' as a >>> separator for the decimal part of a numerical value, the pdf/ps file >>> generated still has the ',' instead of a '.' causing problem when open >>> the resulting file with a postscript/pdf viewer. >>> >>> Of course, an obvious workaround would be to force the locale for >>> numbers to C ( LC_NUMERIC = "C" ), but that could be overriding >>> internationalization features otherwise in R. >>> >>> Any advice ? >> >> Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that. >> It used to cause far more problems than this. >> > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ali.baharev at gmail.com Sun Nov 16 17:06:37 2008 From: ali.baharev at gmail.com (Ali Baharev) Date: Sun, 16 Nov 2008 17:06:37 +0100 Subject: [Rd] Computing minimal detectable differences for general ANOVA models Message-ID: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> Dear Developers, I would like to contribute to the R Project. I implemented a C function the can be used to calculate minimal detectable differences for general ANOVA models (sample size calculations, power analysis). A demo program and the source code is available from my website: http://reliablecomputing.eu/ncbeta.html What should i do in order to make my ncbeta function part of the R project source distribution? Probably the most troublesome parts of my code are those where error may occur, i do not know much about the proper error handling in R. Many thanks, Ali P.S. I see my suggestions https://stat.ethz.ch/pipermail/r-devel/2008-April/049317.html were considered in R 2.8.0. From lgautier at gmail.com Sun Nov 16 17:25:25 2008 From: lgautier at gmail.com (laurent) Date: Sun, 16 Nov 2008 17:25:25 +0100 Subject: [Rd] problem with postscript/pdf plots, locales and embedded R In-Reply-To: References: <1226690614.8615.26.camel@hot-spring> <1226771389.23719.14.camel@hot-spring> Message-ID: <1226852725.6721.50.camel@hot-spring> That might also be reporting something that can be felt like a brittle aspect of R when embedded. I am very tempted to ask why enforcing LC_NUMERIC to "C" for the whole process while this only concerns numerical values written into "data" files. I am understanding that at least postscript/pdf files are affected, and so might files representing R serialized objects. Functions like glib's 'g_ascii_dtostr()/g_ascii_strtod()' appear to have been developed for such purposes, for example. L. On Sun, 2008-11-16 at 12:40 +0000, Prof Brian Ripley wrote: > You start from a false premise, and it seems that you are reporting a > serious bug in Rpy to the wrong list: > > Note that R expects to be run with the locale category `LC_NUMERIC' set > to its default value of C, and so should not be embedded into an > application which changes that. > > ('Writing R Extensions'). > > On Sat, 15 Nov 2008, laurent wrote: > > > Thanks for the quick answer. > > > > The documentation for Sys.setlocale mentions the possibility of warning > > when LC_NUMERIC is set. > > > > After checking it is looking like setting LC_NUMERIC from Sys.setlocale > > does issue a warning, but there is does not seem to be a warning when > > LC_NUMERIC is set in the parent shell. In the case the later is likely > > to cause trouble, would it be appropriate to issue a warning when R is > > initialized ? > > Of course R does not violate its own documentation. None of the R > executables reset the LC_NUMERIC locale category, and all C programs start > in the 'C' locale (both facts you should have known from the homework > you did before posting). > > BDR > > > > > > > Laurent > > > > > > > > On Fri, 2008-11-14 at 19:37 +0000, Prof Brian Ripley wrote: > >> On Fri, 14 Nov 2008, laurent wrote: > >> > >>> Dear list, > >>> > >>> A problem with creating pdf or postscript plots from an embedded R, and > >>> in an environment where a locale is defined, was recently reported on > >>> the rpy (Python->R interface) mailing list. > >>> > >>> The problem appears to be that whenever the locale defines ',' as a > >>> separator for the decimal part of a numerical value, the pdf/ps file > >>> generated still has the ',' instead of a '.' causing problem when open > >>> the resulting file with a postscript/pdf viewer. > >>> > >>> Of course, an obvious workaround would be to force the locale for > >>> numbers to C ( LC_NUMERIC = "C" ), but that could be overriding > >>> internationalization features otherwise in R. > >>> > >>> Any advice ? > >> > >> Don't set LC_NUMERIC with R: ?Sys.setlocale did warn you about that. > >> It used to cause far more problems than this. > >> > > > From ripley at stats.ox.ac.uk Sun Nov 16 17:30:54 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Sun, 16 Nov 2008 16:30:54 +0000 (GMT) Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> Message-ID: On Sun, 16 Nov 2008, Ali Baharev wrote: > Dear Developers, > > I would like to contribute to the R Project. > > I implemented a C function the can be used to calculate minimal > detectable differences for general ANOVA models (sample size > calculations, power analysis). > > A demo program and the source code is available from my website: > > http://reliablecomputing.eu/ncbeta.html > > What should i do in order to make my ncbeta function part of the R > project source distribution? Everyone can contribute code as a package: code in the source distribution is by members of R-core only, including in a few cases code they choose to adopt (with permission) from others. Most importantly, R-core has to commit to maintenance of such code indefinitely, and these days we are very reluctant to do so. > Probably the most troublesome parts of my code are those where error > may occur, i do not know much about the proper error handling in R. So you need to find out before distributing a package. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From duncan at wald.ucdavis.edu Sun Nov 16 17:53:12 2008 From: duncan at wald.ucdavis.edu (Duncan Temple Lang) Date: Sun, 16 Nov 2008 08:53:12 -0800 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> Message-ID: <49204FF8.9040706@wald.ucdavis.edu> Ali Baharev wrote: > Dear Developers, > > I would like to contribute to the R Project. > > I implemented a C function the can be used to calculate minimal > detectable differences for general ANOVA models (sample size > calculations, power analysis). > > A demo program and the source code is available from my website: > > http://reliablecomputing.eu/ncbeta.html > > What should i do in order to make my ncbeta function part of the R > project source distribution? As Brian said in a separate message, build an R package and distribute one or more R documented functions that all the C code. See the Writing R Extension's manual. > > Probably the most troublesome parts of my code are those where error > may occur, i do not know much about the proper error handling in R. Calls to exit() as in your C code should be replaced with calls to PROBLEM "the error message" ERROR Again, the R manuals (Writing R Extensions) will give you the information you need. > > Many thanks, > > Ali > > P.S. I see my suggestions > https://stat.ethz.ch/pipermail/r-devel/2008-April/049317.html > were considered in R 2.8.0. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From pburns at pburns.seanet.com Sun Nov 16 20:22:13 2008 From: pburns at pburns.seanet.com (Patrick Burns) Date: Sun, 16 Nov 2008 19:22:13 +0000 Subject: [Rd] 'by' with one-dimensional array Message-ID: <492072E5.8050608@pburns.seanet.com> I've played a bit with the problem that Jeff Laake reported on R-help: # create data: jl <- data.frame(x=rep(1, 3), y=tapply(1:9, rep(c('A','B','C'), each=3), sum)) jl2 <- jl jl2$y <- as.numeric(jl2$y) # do the test: > tapply(jl$y, jl$x, length) 1 3 > tapply(jl2$y, jl2$x, length) 1 3 > by(jl2$y, jl2$x, length) jl2$x: 1 [1] 3 > by(jl$y, jl$x, length) INDICES: 1 [1] 1 The result of 'by' on the 1-dimensional array is giving the correct answer to a question that I don't think many of us thought we were asking. Once upon a time 'by' gave 3 as the answer in both situations. 'by.default' used to be a one-liner, but now decides what to do based on 'length(dim(data))'. This specific problem goes away if the line: if (length(dim(data))) is replaced by: if(length(dim(data)) > 1) But I don't know what other mischief such a change would make. Patrick Burns patrick at burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") From aredd at stat.tamu.edu Mon Nov 17 01:39:26 2008 From: aredd at stat.tamu.edu (Andrew Redd) Date: Sun, 16 Nov 2008 18:39:26 -0600 Subject: [Rd] Diagnosing Crashes on garbage collection Message-ID: <4d17c3500811161639t6619ba24p158de02b5a96b6a6@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From tlumley at u.washington.edu Mon Nov 17 02:01:21 2008 From: tlumley at u.washington.edu (Thomas Lumley) Date: Sun, 16 Nov 2008 17:01:21 -0800 (PST) Subject: [Rd] Diagnosing Crashes on garbage collection In-Reply-To: <4d17c3500811161639t6619ba24p158de02b5a96b6a6@mail.gmail.com> References: <4d17c3500811161639t6619ba24p158de02b5a96b6a6@mail.gmail.com> Message-ID: On Sun, 16 Nov 2008, Andrew Redd wrote: > I'm having problems with an access violation error on some compiled code > that I'm writing and I was hoping that some one had insights as to what > might be causing the access violation and possibly how to remedy it. If you are using (or can use) Linux, then valgrind is an excellent tool for this. There's some documentation in 'Writing R Extensions'. Valgrind runs your code in a virtual machine and tracks all memory accesses, so it often will even find bugs in C code that are hard to reproduce. -thomas Thomas Lumley Assoc. Professor, Biostatistics tlumley at u.washington.edu University of Washington, Seattle From p.murrell at auckland.ac.nz Mon Nov 17 02:45:06 2008 From: p.murrell at auckland.ac.nz (Paul Murrell) Date: Mon, 17 Nov 2008 14:45:06 +1300 Subject: [Rd] Fw: alpha transparency crashes R In-Reply-To: References: Message-ID: <4920CCA2.1070704@stat.auckland.ac.nz> Hi Deepayan Sarkar wrote: > I'm forwarding a bug report from Jeff Gove that didn't make it to the list. > -Deepayan > > ------- Original Message -------- > Subject: alpha transparency crashes R > Date: Fri, 07 Nov 2008 14:32:27 -0500 > From: jeff gove > To: r-bugs at r-project.org > > > I ran into a problem with R crashing when a certain number of > transparent objects (e.g., symbols) are sent to a PDF output device. > This has happened on R 2.71, 2.7.2 (Fedora 8 and Ububtu 8.04 > platforms) and now 2.8.0 (I've only tried Fedora 8). The current > pertinent R system stats are... > > R.version > _ > platform x86_64-redhat-linux-gnu > arch x86_64 > os linux-gnu > system x86_64, linux-gnu > status > major 2 > minor 8.0 > year 2008 > month 10 > day 20 > svn rev 46754 > language R > version.string R version 2.8.0 (2008-10-20) > > The following small example program when run with n large enough > (e.g., n=1000) and transparency will crash R... > > alphaBomb.r = function(n=100, wantAlpha=T) { > df = data.frame(a=rnorm(n),b=runif(n)) > if(wantAlpha) > alpha=runif(n) > else > alpha = 1 > j = xyplot(b~a, df, alpha=alpha, pch=19) > print(j) > trellis.device('pdf',file='alphaBomb.pdf',version='1.4') > print(j) > dev.off() > } > > Please note that the crash seems to occur in the dev.off() component, > and that the file actually seems to get written out correctly. The > trace of the bomb is found below, excluding the memory map. Please > also note that it may be somehow related to grid, as the following > code (supplied by Deepayan Sarkar) using base graphics does not crash > R, even with n=100000... > > pdf() > n = 1000 > plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 16) > dev.off() Grid runs laughing from your puny accusations! This will tickle the problem too: plot(rnorm(n), rnorm(n), col = rgb(0, 0, 0, alpha = runif(n)), pch = 19) The issue appears to be in the PDF device driver, which has a fixed-size integer array called pd->pos and those larger examples are generating "too many" different alpha values so that we end up assigning values out-of-range for that array. The simple fix is to bump up the initial size of the pd->pos array, but there is some heuristic code in devPS.c (PDF_NewPage) that appears to be trying to resize the array on-the-fly based on how many pages are being generated, so perhaps this needs a bit more thought. Thanks for the bug report! Paul > The error trace from the above alphaBomb.r() code is... > > R> alphaBomb.r(100) #this is fine > X11cairo > 2 > > R> alphaBomb.r(1000,F) #also fine > > R> alphaBomb.r(1000) > *** glibc detected *** /usr/lib64/R/bin/exec/R: double free or > corruption (!prev): 0x00000000032c1d90 *** > ======= Backtrace: ========= > /lib64/libc.so.6[0x3ee8c72832] > /lib64/libc.so.6(cfree+0x8c)[0x3ee8c75f2c] > /usr/lib64/R/library/grDevices/libs/grDevices.so[0x2aaab000b0fc] > /usr/lib64/R/lib/libR.so[0x3d1f48ddd3] > /usr/lib64/R/lib/libR.so[0x3d1f48e2dc] > /usr/lib64/R/lib/libR.so[0x3d1f4ec81c] > /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] > /usr/lib64/R/lib/libR.so[0x3d1f4bf572] > /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] > /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1] > /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783] > /usr/lib64/R/lib/libR.so[0x3d1f4bf572] > /usr/lib64/R/lib/libR.so(Rf_eval+0x42e)[0x3d1f4be8ae] > /usr/lib64/R/lib/libR.so(Rf_applyClosure+0x291)[0x3d1f4c0bf1] > /usr/lib64/R/lib/libR.so(Rf_eval+0x303)[0x3d1f4be783] > /usr/lib64/R/lib/libR.so(Rf_ReplIteration+0x188)[0x3d1f4dc878] > /usr/lib64/R/lib/libR.so[0x3d1f4dcb90] > /usr/lib64/R/lib/libR.so(run_Rmainloop+0x50)[0x3d1f4dcec0] > /usr/lib64/R/bin/exec/R(main+0x1b)[0x40082b] > /lib64/libc.so.6(__libc_start_main+0xf4)[0x3ee8c1e074] > /usr/lib64/R/bin/exec/R[0x400729] > ======= Memory map: ======== > etc... > > Please note that R only crashes with PDF output; tiff, png and eps > (even though it doesn't accept transparency) all exit cleanly. > > My version of glibc is 2.7. > > Thanks, I hope that the problem is already resolved! > > Jeff > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 paul at stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ From charlie.xia.fdu at gmail.com Mon Nov 17 04:11:55 2008 From: charlie.xia.fdu at gmail.com (charlie) Date: Sun, 16 Nov 2008 19:11:55 -0800 Subject: [Rd] Fwd: Fwd: SWIG with R and C++ STL In-Reply-To: <11c6cf4e0811161910v25ce5f30r71e891673612c078@mail.gmail.com> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> <8ec76080811061129p2e54125eqee948a31bb4a4de8@mail.gmail.com> <11c6cf4e0811161910v25ce5f30r71e891673612c078@mail.gmail.com> Message-ID: <11c6cf4e0811161911y49ded77di905fc86ea630f4b5@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From edd at debian.org Mon Nov 17 05:26:27 2008 From: edd at debian.org (Dirk Eddelbuettel) Date: Sun, 16 Nov 2008 22:26:27 -0600 Subject: [Rd] Fwd: Fwd: SWIG with R and C++ STL In-Reply-To: <11c6cf4e0811161911y49ded77di905fc86ea630f4b5@mail.gmail.com> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> <8ec76080811061129p2e54125eqee948a31bb4a4de8@mail.gmail.com> <11c6cf4e0811161910v25ce5f30r71e891673612c078@mail.gmail.com> <11c6cf4e0811161911y49ded77di905fc86ea630f4b5@mail.gmail.com> Message-ID: <18720.62067.394678.969716@ron.nulle.part> I don't know about your examples from section 5.4.9 of the swig manual, but the very basic SWIG example I have played with still works: edd at ron:~/src/progs/swig/R> cat example.c /* File : example.c */ double My_variable = 3.0; /* Compute factorial of n */ int fact(int n) { if (n <= 1) return 1; else return n*fact(n-1); } /* Compute n mod m */ int my_mod(int n, int m) { return(n % m); } edd at ron:~/src/progs/swig/R> cat example.i /* File : example.i */ %module example %{ /* Put headers and other declarations here */ extern double My_variable; extern int fact(int); extern int my_mod(int n, int m); %} extern double My_variable; extern int fact(int); extern int my_mod(int n, int m); edd at ron:~/src/progs/swig/R> cat testR.r #!/usr/bin/r dyn.load("example_wrap.so") source("example_wrap.R") print(fact(4)) print(My_variable_get()) print(my_mod(77,66)) edd at ron:~/src/progs/swig/R> cat makeR.sh #!/bin/sh set +e set +u rm -vf *.o *.so swig -r example.i PKG_LIBS="example.c" R CMD SHLIB example_wrap.c #./testR.sh ./testR.r ./testR.redd at ron:~/src/progs/swig/R> ./makeR.sh removed `example_wrap.o' removed `example_wrap.so' gcc -std=gnu99 -I/usr/share/R/include -fpic -g -O2 -c example_wrap.c -o example_wrap.o gcc -std=gnu99 -shared -o example_wrap.so example_wrap.o example.c -L/usr/lib/R/lib -lR Creating a new generic function for "print" in ".GlobalEnv" [1] 24 [1] 3 [1] 11 edd at ron:~/src/progs/swig/R> I haven't really tried anything much more complicated. Swig 1.3.36, R 2.8.0, g++ 4.3.2 on Debian testing. Hope this helps, Dirk -- Three out of two people have difficulties with fractions. From ripley at stats.ox.ac.uk Mon Nov 17 06:53:15 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 17 Nov 2008 05:53:15 +0000 (GMT) Subject: [Rd] Diagnosing Crashes on garbage collection In-Reply-To: References: <4d17c3500811161639t6619ba24p158de02b5a96b6a6@mail.gmail.com> Message-ID: On Sun, 16 Nov 2008, Thomas Lumley wrote: > On Sun, 16 Nov 2008, Andrew Redd wrote: > >> I'm having problems with an access violation error on some compiled code >> that I'm writing and I was hoping that some one had insights as to what >> might be causing the access violation and possibly how to remedy it. > > If you are using (or can use) Linux, then valgrind is an excellent tool for > this. There's some documentation in 'Writing R Extensions'. Valgrind runs > your code in a virtual machine and tracks all memory accesses, so it often > will even find bugs in C code that are hard to reproduce. And if it is R's garbage collection that is the issue, using gctorture(TRUE) (with valgrind if possible) will provoke the problem at the earlist opportunity. There is a section in 'Writing R Extensions' on that too. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From constant at unb.br Sun Nov 16 01:00:09 2008 From: constant at unb.br (constant at unb.br) Date: Sun, 16 Nov 2008 01:00:09 +0100 (CET) Subject: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292) Message-ID: <20081116000009.8029A2834615@mail.pubhealth.ku.dk> Full_Name: Reginaldo Constantino Version: 2.8.0 OS: Ubuntu Hardy (32 bit, kernel 2.6.24) Submission from: (NULL) (189.61.88.2) For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is obviously incorrect and inversely proportional to the number of replicates: > data(HairEyeColor) > x <- margin.table(HairEyeColor, c(1, 2)) > chisq.test(x,simulate.p.value=TRUE,B=2000) Pearson's Chi-squared test with simulated p-value (based on 2000 replicates) data: x X-squared = 138.2898, df = NA, p-value = 0.0004998 > chisq.test(x,simulate.p.value=TRUE,B=10000) X-squared = 138.2898, df = NA, p-value = 1e-04 > chisq.test(x,simulate.p.value=TRUE,B=100000) X-squared = 138.2898, df = NA, p-value = 1e-05 > chisq.test(x,simulate.p.value=TRUE,B=1000000) X-squared = 138.2898, df = NA, p-value = 1e-06 ... Also tested the same R version under Windows XP and got the same results. From xieyihui at gmail.com Sat Nov 15 02:44:47 2008 From: xieyihui at gmail.com (Yihui Xie) Date: Sat, 15 Nov 2008 09:44:47 +0800 Subject: [Rd] (PR#13287) Line breaks in mathematical formulae in Rd files In-Reply-To: References: <20081114131503.B9F522834620@mail.pubhealth.ku.dk> Message-ID: <89b6b8c90811141744k64000296p35aa1bb98633fc29@mail.gmail.com> Thanks, Prof Ripley, I do have noticed the manual; what I mean is the "displaymath" environment might not be appropriate for R documentation when there are multiple lines of formulae; I'm sorry this seems to be a suggestion rather than a bug... According to your response, the only solution is write several displayed equations when a single equation is too long? Regards, Yihui -- Yihui Xie Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086 Mobile: +86-15810805877 Homepage: http://www.yihui.name School of Statistics, Room 1037, Mingde Main Building, Renmin University of China, Beijing, 100872, China On Sat, Nov 15, 2008 at 12:29 AM, Prof Brian Ripley wrote: > I think the 'problem' is a lack of attention to the manual. > > deqn gives "displayed equations" (as in LaTeX's displaymath environment, > or TeX's $$...$$). > > seems pretty clear to me, and I hope to any LaTeX user. > > On Fri, 14 Nov 2008, xieyihui at gmail.com wrote: > >> Hi, >> >> This is a problem about writing R documentation (R-exts 2.6). The >> command "\deqn" defined in "Rd.sty" is: >> >> \newcommand{\deqn}[2]{\[#1\]} >> >> which will put mathematical formulae in the "displaymath" environment; > > Well, surprise, surprise it does what it is documented to do! > I didn't mean there was something wrong - I was just explaining the definition which could be modified as below. >> that means line breaks are not allowed (or will not be shown) in >> formulae, but sometimes we do need multiple lines of formulae. One >> solution is to write several equations using "\deqn", but I think to >> change the definition of "\deqn" is better: >> >> \newcommand{\deqn}[2]{\begin{eqnarray*}#1\end{eqnarray*}} > > That will change the spacing. > >> This will not change the pdfLaTeX output effect, moreover, line breaks >> and alignments using "&" will be available in math formulae. > > Not to the non-latex conversions. OK, I see. Thanks! > >> Regards, >> Yihui >> -- >> Yihui Xie >> Phone: +86-(0)10-82509086 Fax: +86-(0)10-82509086 >> Mobile: +86-15810805877 >> Homepage: http://www.yihui.name >> School of Statistics, Room 1037, Mingde Main Building, >> Renmin University of China, Beijing, 100872, China >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Brian D. Ripley, ripley at stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 From rose at rz.uni-potsdam.de Sun Nov 16 17:50:07 2008 From: rose at rz.uni-potsdam.de (rose at rz.uni-potsdam.de) Date: Sun, 16 Nov 2008 17:50:07 +0100 (CET) Subject: [Rd] help.start() displays index.html in emacs (PR#13293) Message-ID: <20081116165007.98C0A282C774@mail.pubhealth.ku.dk> Full_Name: Juergen Rose Version: 2.8.0 (2008-10-20) OS: Linux 2.6.27.4 x86_64 Intel Submission from: (NULL) (87.185.220.122) If I start as ordinary user rose R and help.start(), the help is displayed in emacs. If I do as the user root, file:///tmp/Rtmpyzlc7Y/.R/doc/html/index.html is shown as expected in a firefox windows. So it seems to be connected with my private configuration. But I can not find such a configurations: rose at condor:/home/rose(114)$ ll ~/.R* -rw-r--r-- 1 rose users 2369 Jan 20 2008 /home/rose/.RapidSVN I also tried to start R with strace: rose at condor:/home/rose(119)$ strace -f -o R_strace.log R and greped for mime: rose at condor:/home/rose(120)$ grep "open.*rose.*mime" R_strace.log 7221 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 14 7221 open("/home/rose/.local/share/applications/mimeinfo.cache", O_RDONLY) = 14 7221 open("/home/rose/.local/share/applications/mimeapps.list", O_RDONLY) = 14 7223 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 7 and then I searched for emacs in these files: rose at condor:/home/rose(121)$ for f in /home/rose/.local/share//mime/mime.cache /home/rose/.local/share/applications/mimeinfo.cache /home/rose/.local/share/applications/mimeapps.list /home/rose/.local/share//mime/mime.cache; do echo "------------------ f=$f --------------"; grep emacs $f ; done ------------------ f=/home/rose/.local/share//mime/mime.cache -------------- ------------------ f=/home/rose/.local/share/applications/mimeinfo.cache -------------- application/x-x509-ca-cert=emacs-21-usercustom.desktop ------------------ f=/home/rose/.local/share/applications/mimeapps.list -------------- ------------------ f=/home/rose/.local/share//mime/mime.cache -------------- But I could not find anything suspicious From ripley at stats.ox.ac.uk Mon Nov 17 09:03:39 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 17 Nov 2008 08:03:39 +0000 (GMT) Subject: [Rd] help.start() displays index.html in emacs (PR#13293) In-Reply-To: <20081116165007.98C0A282C774@mail.pubhealth.ku.dk> References: <20081116165007.98C0A282C774@mail.pubhealth.ku.dk> Message-ID: On Sun, 16 Nov 2008, rose at rz.uni-potsdam.de wrote: > Full_Name: Juergen Rose > Version: 2.8.0 (2008-10-20) > OS: Linux 2.6.27.4 x86_64 Intel > Submission from: (NULL) (87.185.220.122) > > > If I start as ordinary user rose R and help.start(), the help is displayed in > emacs. If I do as the user root, file:///tmp/Rtmpyzlc7Y/.R/doc/html/index.html > is shown as expected in a firefox windows. So it seems to be connected with my > private configuration. But I can not find such a configurations: So why report this as a bug in R (especially without reading the help pages concerned)? help.start uses R_BROWSER to select the browser in use via browseURL: see the help for help.start and browseURL. Check options("browser") in each of the accounts. Another thing you have not told us is how you installed R: the default for R_BROWSER is set at install time in R_HOME/etc/Renviron. However, as it works correctly for 'root', I guess it is your account that has some setting of the browser to be used. > > rose at condor:/home/rose(114)$ ll ~/.R* > -rw-r--r-- 1 rose users 2369 Jan 20 2008 /home/rose/.RapidSVN > > I also tried to start R with strace: > rose at condor:/home/rose(119)$ strace -f -o R_strace.log R > > and greped for mime: > > rose at condor:/home/rose(120)$ grep "open.*rose.*mime" R_strace.log > 7221 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 14 > 7221 open("/home/rose/.local/share/applications/mimeinfo.cache", O_RDONLY) = > 14 > 7221 open("/home/rose/.local/share/applications/mimeapps.list", O_RDONLY) = 14 > 7223 open("/home/rose/.local/share//mime/mime.cache", O_RDONLY) = 7 > > and then I searched for emacs in these files: > > > rose at condor:/home/rose(121)$ for f in /home/rose/.local/share//mime/mime.cache > /home/rose/.local/share/applications/mimeinfo.cache > /home/rose/.local/share/applications/mimeapps.list > /home/rose/.local/share//mime/mime.cache; do echo "------------------ f=$f > --------------"; grep emacs $f ; done > ------------------ f=/home/rose/.local/share//mime/mime.cache -------------- > ------------------ f=/home/rose/.local/share/applications/mimeinfo.cache > -------------- > application/x-x509-ca-cert=emacs-21-usercustom.desktop > ------------------ f=/home/rose/.local/share/applications/mimeapps.list > -------------- > ------------------ f=/home/rose/.local/share//mime/mime.cache -------------- > > But I could not find anything suspicious > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From berwin at maths.uwa.edu.au Mon Nov 17 09:23:03 2008 From: berwin at maths.uwa.edu.au (Berwin A Turlach) Date: Mon, 17 Nov 2008 16:23:03 +0800 Subject: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292) In-Reply-To: <20081116000009.8029A2834615@mail.pubhealth.ku.dk> References: <20081116000009.8029A2834615@mail.pubhealth.ku.dk> Message-ID: <20081117162303.2f434889@berwin-nus1> G'day Reginaldo, On Sun, 16 Nov 2008 01:00:09 +0100 (CET) constant at unb.br wrote: > Full_Name: Reginaldo Constantino > Version: 2.8.0 > OS: Ubuntu Hardy (32 bit, kernel 2.6.24) > Submission from: (NULL) (189.61.88.2) > > > For many tables, chisq.test with simulate.p.value=TRUE gives a p > value that is obviously incorrect and inversely proportional to the > number of replicates: Why is this Monte-Carlo p-value obviously incorrect? In your example, did you look at the observed ChiSquare statistics? Any idea how likely it is to observe a value that is at least as extreme as the one observed? Essentially, you are doing B Monte-Carlo simulations and in none of these simulations do you obtain a statistic that is at least as extreme as the one that you have observed. So your Monte-Carlo p-value ends up to be 1/(B+1). I do not see any problem or bug here. > > data(HairEyeColor) > > x <- margin.table(HairEyeColor, c(1, 2)) > > chisq.test(x,simulate.p.value=TRUE,B=2000) > Pearson's Chi-squared test with simulated p-value (based on > 2000 replicates) > data: x > X-squared = 138.2898, df = NA, p-value = 0.0004998 > > > chisq.test(x,simulate.p.value=TRUE,B=10000) > X-squared = 138.2898, df = NA, p-value = 1e-04 > > > chisq.test(x,simulate.p.value=TRUE,B=100000) > X-squared = 138.2898, df = NA, p-value = 1e-05 > > > chisq.test(x,simulate.p.value=TRUE,B=1000000) > X-squared = 138.2898, df = NA, p-value = 1e-06 > ... > > Also tested the same R version under Windows XP and got the same > results. Cheers, Berwin =========================== Full address ============================= Berwin A Turlach Tel.: +65 6516 4416 (secr) Dept of Statistics and Applied Probability +65 6516 6650 (self) Faculty of Science FAX : +65 6872 3919 National University of Singapore 6 Science Drive 2, Blk S16, Level 7 e-mail: statba at nus.edu.sg Singapore 117546 http://www.stat.nus.edu.sg/~statba From h.wickham at gmail.com Mon Nov 17 14:10:10 2008 From: h.wickham at gmail.com (hadley wickham) Date: Mon, 17 Nov 2008 07:10:10 -0600 Subject: [Rd] stringsAsFactors = FALSE Message-ID: Hi all, I love the option to not automatically convert strings into factors, but there are three places that the current option doesn't work where I think it should: options(stringsAsFactors = FALSE) str(expand.grid(letters)) str(type.convert(letters)) df <- read.fwf(textConnection(paste(letters,collapse="\n")), 1) str(df) I think type.convert and read.fwf can be fixed by giving them a stringsAsFactors argument and then using asis = !stringsAsFactors (like read.table). The key lines in expand.grid would seem to be if (!is.factor(x) && is.character(x)) x <- factor(x, levels = unique(x)) but I'm not sure why they are being converted to factors in the first place. Regards, Hadley -- http://had.co.nz/ From fabien.roussel at imr.no Mon Nov 17 10:50:03 2008 From: fabien.roussel at imr.no (fabien.roussel at imr.no) Date: Mon, 17 Nov 2008 10:50:03 +0100 (CET) Subject: [Rd] R problem with the seq function (PR#13295) Message-ID: <20081117095004.067E7283417B@mail.pubhealth.ku.dk> Hello, =20 Something wrong happens when I use the seq (function). Here it is an exampl= e from my R console, I have the R version 2.7.2 (2008-08-25) running on Mic= rosoft windows XP Version 2002 Service Pack 3, and my machine is a Dell Opt= ilex GX280 with a processor Intel Pentium 4 CPU 2.80GHhz, 0.99 GB RAM: =20 =20 >r=3Dseq(0.150,0.180,0.001) =20 > r[16] =20 [1] 0.165 =20 > class(r[16]) =20 [1] "numeric" =20 > for (i in (150:180)/1000) =20 + show(which(r=3D=3Di)) =20 [1] 1 [1] 2 [1] 3 [1] 4 [1] 5 [1] 6 [1] 7 [1] 8 [1] 9 [1] 10 [1] 11 [1] 12 [1] 13 [1] 14 [1] 15 integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) integer(0) [1] 23 [1] 24 [1] 25 [1] 26 [1] 27 [1] 28 [1] 29 [1] 30 [1] 31 =20 Could you explain me why from the 16th element to the 22nd the value is int= eger (0) ? I really don't understand... so it would be very nice of you to= do it. =20 Best regards=20 =20 Fabien Roussel,=20 Student=20 Institute of Marine Research Troms=F8 Norway [[alternative HTML version deleted]] From ripley at stats.ox.ac.uk Mon Nov 17 15:36:56 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 17 Nov 2008 14:36:56 +0000 (GMT) Subject: [Rd] R problem with the seq function (PR#13295) In-Reply-To: <20081117095004.067E7283417B@mail.pubhealth.ku.dk> References: <20081117095004.067E7283417B@mail.pubhealth.ku.dk> Message-ID: >From the FAQ, section 9.1 If a command does the wrong thing, that is a bug. But be sure you know for certain what it ought to have done. If you aren't familiar with the command, or don't know for certain how the command is supposed to work, then it might actually be working right. For example, people sometimes think there is a bug in R's mathematics because they don't understand how finite-precision arithmetic works. Rather than jumping to conclusions, show the problem to someone who knows for certain. Unexpected results of comparison of decimal numbers, for example `0.28 * 100 != 28' or `0.1 + 0.2 != 0.3', are not a bug. See FAQ 7.31 for more details. As a student, you should seek advice from your teachers about things you 'really don't understand'. On Mon, 17 Nov 2008, fabien.roussel at imr.no wrote: > Hello, > > =20 > > Something wrong happens when I use the seq (function). Here it is an exampl= > e from my R console, I have the R version 2.7.2 (2008-08-25) running on Mic= > rosoft windows XP Version 2002 Service Pack 3, and my machine is a Dell Opt= > ilex GX280 with a processor Intel Pentium 4 CPU 2.80GHhz, 0.99 GB RAM: > > =20 > > =20 > >> r=3Dseq(0.150,0.180,0.001) > > =20 > >> r[16] > > =20 > > [1] 0.165 > > =20 > >> class(r[16]) > > =20 > > [1] "numeric" > > =20 > >> for (i in (150:180)/1000) > > =20 > > + show(which(r=3D=3Di)) > > =20 > > [1] 1 > > [1] 2 > > [1] 3 > > [1] 4 > > [1] 5 > > [1] 6 > > [1] 7 > > [1] 8 > > [1] 9 > > [1] 10 > > [1] 11 > > [1] 12 > > [1] 13 > > [1] 14 > > [1] 15 > > integer(0) > > integer(0) > > integer(0) > > integer(0) > > integer(0) > > integer(0) > > integer(0) > > [1] 23 > > [1] 24 > > [1] 25 > > [1] 26 > > [1] 27 > > [1] 28 > > [1] 29 > > [1] 30 > > [1] 31 > > =20 > > Could you explain me why from the 16th element to the 22nd the value is int= > eger (0) ? I really don't understand... so it would be very nice of you to= > do it. > > =20 > > Best regards=20 > > =20 > > Fabien Roussel,=20 > > Student=20 > > Institute of Marine Research Troms=F8 > > Norway > > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Mon Nov 17 16:03:16 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 17 Nov 2008 15:03:16 +0000 (GMT) Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: References: Message-ID: On Mon, 17 Nov 2008, hadley wickham wrote: > Hi all, > > I love the option to not automatically convert strings into factors, > but there are three places that the current option doesn't work where > I think it should: Perhaps you mean 'when I would like it to'? Things *should* work as documented, surely? > options(stringsAsFactors = FALSE) > > str(expand.grid(letters)) > str(type.convert(letters)) > > df <- read.fwf(textConnection(paste(letters,collapse="\n")), 1) > str(df) I get > str(df) 'data.frame': 26 obs. of 1 variable: $ V1: chr "a" "b" "c" "d" ... so what is wrong with that? read.fwf just calls read.table, so the default options of read.table apply. > I think type.convert and read.fwf can be fixed by giving them a > stringsAsFactors argument and then using asis = !stringsAsFactors > (like read.table). Seems to me that there is nothing wrong with read.fwf. For type.convert() we could have the default as.is = !default.stringsAsFactors() but I think a strong case needs to be made to change the documented behaviour. > The key lines in expand.grid would seem to be > > if (!is.factor(x) && is.character(x)) > x <- factor(x, levels = unique(x)) > > but I'm not sure why they are being converted to factors in the first place. Nor I am, but it goes back to at least r2107, over 10 years ago. I don't see much problem with adding a 'stringsAsFactors' argument there. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From wdunlap at tibco.com Mon Nov 17 18:06:49 2008 From: wdunlap at tibco.com (William Dunlap) Date: Mon, 17 Nov 2008 09:06:49 -0800 Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: References: Message-ID: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of hadley wickham > Sent: Monday, November 17, 2008 5:10 AM > To: r-devel at r-project.org > Subject: [Rd] stringsAsFactors = FALSE > ... > The key lines in > expand.grid would seem to be > > if (!is.factor(x) && is.character(x)) > x <- factor(x, levels = unique(x)) > > but I'm not sure why they are being converted to factors in > the first place. I think expand.grid converts input strings to factors so they retain the order they have in the input. (Note that the levels argument is unique(x), not the sort(unique(x)) that data.frame uses.) People generally give expand.grid sorted input and expect it to not alter the order (the order of the levels affects tables and and some plots). > lapply(expand.grid(Grade=c("Bad","Good","Better"),Size=c("Small","Medium ","Large")), levels) $Grade [1] "Bad" "Good" "Better" $Size [1] "Small" "Medium" "Large" > lapply(data.frame(Grade=c("Bad","Good","Better"),Size=c("Small","Medium" ,"Large")), levels) $Grade [1] "Bad" "Better" "Good" $Size [1] "Large" "Medium" "Small" I have nothing against adding the stringsAsFactors argument to expand.grid. Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com From ripley at stats.ox.ac.uk Mon Nov 17 18:14:46 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Mon, 17 Nov 2008 17:14:46 +0000 (GMT) Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: References: Message-ID: On Mon, 17 Nov 2008, Prof Brian Ripley wrote: > On Mon, 17 Nov 2008, hadley wickham wrote: > >> Hi all, >> >> I love the option to not automatically convert strings into factors, >> but there are three places that the current option doesn't work where >> I think it should: > > Perhaps you mean 'when I would like it to'? Things *should* work as > documented, surely? > >> options(stringsAsFactors = FALSE) >> >> str(expand.grid(letters)) >> str(type.convert(letters)) >> >> df <- read.fwf(textConnection(paste(letters,collapse="\n")), 1) >> str(df) > > I get > >> str(df) > 'data.frame': 26 obs. of 1 variable: > $ V1: chr "a" "b" "c" "d" ... > > so what is wrong with that? read.fwf just calls read.table, so the default > options of read.table apply. > >> I think type.convert and read.fwf can be fixed by giving them a >> stringsAsFactors argument and then using asis = !stringsAsFactors >> (like read.table). > > Seems to me that there is nothing wrong with read.fwf. For type.convert() we > could have the default > > as.is = !default.stringsAsFactors() > > but I think a strong case needs to be made to change the documented > behaviour. It seems only to be used in RODBC (where I have some extra control pending), simecol and BioC:beadarraySNP (both with as.is=TRUE) and reshape (author, one Hadley Wickham). Given it is documented as a help utilty, it seems up to the caller to set the behaviour he wants. > >> The key lines in expand.grid would seem to be >> >> if (!is.factor(x) && is.character(x)) >> x <- factor(x, levels = unique(x)) >> >> but I'm not sure why they are being converted to factors in the first >> place. > > Nor I am, but it goes back to at least r2107, over 10 years ago. I don't see > much problem with adding a 'stringsAsFactors' argument there. > > -- > Brian D. Ripley, ripley at stats.ox.ac.uk > 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, UK Fax: +44 1865 272595 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From h.wickham at gmail.com Mon Nov 17 18:32:36 2008 From: h.wickham at gmail.com (hadley wickham) Date: Mon, 17 Nov 2008 11:32:36 -0600 Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: References: Message-ID: On Mon, Nov 17, 2008 at 9:03 AM, Prof Brian Ripley wrote: > On Mon, 17 Nov 2008, hadley wickham wrote: > >> Hi all, >> >> I love the option to not automatically convert strings into factors, >> but there are three places that the current option doesn't work where >> I think it should: > > Perhaps you mean 'when I would like it to'? Things *should* work as > documented, surely? In an ideal world, I think things should be documented *and* consistent. >> options(stringsAsFactors = FALSE) >> >> str(expand.grid(letters)) >> str(type.convert(letters)) >> >> df <- read.fwf(textConnection(paste(letters,collapse="\n")), 1) >> str(df) > > I get > >> str(df) > > 'data.frame': 26 obs. of 1 variable: > $ V1: chr "a" "b" "c" "d" ... > > so what is wrong with that? read.fwf just calls read.table, so the default > options of read.table apply. Ok, that's weird. I get factors. >> I think type.convert and read.fwf can be fixed by giving them a >> stringsAsFactors argument and then using asis = !stringsAsFactors >> (like read.table). > > Seems to me that there is nothing wrong with read.fwf. For type.convert() > we could have the default > > as.is = !default.stringsAsFactors() > > but I think a strong case needs to be made to change the documented > behaviour. Well, my intuition was that type.convert should mirror the behaviour of read.table, since it is what does the conversion behind the scenes. I can of course change my own code. >> The key lines in expand.grid would seem to be >> >> if (!is.factor(x) && is.character(x)) >> x <- factor(x, levels = unique(x)) >> >> but I'm not sure why they are being converted to factors in the first >> place. > > Nor I am, but it goes back to at least r2107, over 10 years ago. I don't > see much problem with adding a 'stringsAsFactors' argument there. Great, thanks. Hadley -- http://had.co.nz/ From h.wickham at gmail.com Mon Nov 17 18:34:02 2008 From: h.wickham at gmail.com (hadley wickham) Date: Mon, 17 Nov 2008 11:34:02 -0600 Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> References: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> Message-ID: On Mon, Nov 17, 2008 at 11:06 AM, William Dunlap wrote: >> From: r-devel-bounces at r-project.org >> [mailto:r-devel-bounces at r-project.org] On Behalf Of hadley wickham >> Sent: Monday, November 17, 2008 5:10 AM >> To: r-devel at r-project.org >> Subject: [Rd] stringsAsFactors = FALSE >> ... >> The key lines in >> expand.grid would seem to be >> >> if (!is.factor(x) && is.character(x)) >> x <- factor(x, levels = unique(x)) >> >> but I'm not sure why they are being converted to factors in >> the first place. > > I think expand.grid converts input strings to factors so they > retain the order they have in the input. (Note that the levels > argument is unique(x), not the sort(unique(x)) that data.frame uses.) > People generally give expand.grid sorted input and expect it to > not alter the order (the order of the levels affects tables and > and some plots). Ah, that makes sense. (Although the conversion to factors just seems to be a convenient way to achieve the desired effect in this case - there's no reason they have to be factors in the output) Hadley -- http://had.co.nz/ From p.dalgaard at biostat.ku.dk Mon Nov 17 18:43:16 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Mon, 17 Nov 2008 18:43:16 +0100 Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> References: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> Message-ID: <4921AD34.70404@biostat.ku.dk> William Dunlap wrote: >> but I'm not sure why they are being converted to factors in >> the first place. > > I think expand.grid converts input strings to factors so they > retain the order they have in the input. Yep. These things do matter. Incidentally, I recently got burned by cooking an example using expand.grid, writing the data to a file with write.table and reading it back in during lecture with read.table. Odds ratio turned upside down... -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From maechler at stat.math.ethz.ch Mon Nov 17 21:47:34 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Mon, 17 Nov 2008 21:47:34 +0100 Subject: [Rd] stringsAsFactors = FALSE In-Reply-To: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> References: <77EB52C6DD32BA4D87471DCD70C8D70028E443@NA-PA-VBE03.na.tibco.com> Message-ID: <18721.55398.233830.123451@cmath-5.math.ethz.ch> >>>>> "WD" == William Dunlap >>>>> on Mon, 17 Nov 2008 09:06:49 -0800 writes: >> From: r-devel-bounces at r-project.org >> [mailto:r-devel-bounces at r-project.org] On Behalf Of >> hadley wickham Sent: Monday, November 17, 2008 5:10 AM >> To: r-devel at r-project.org Subject: [Rd] stringsAsFactors >> = FALSE ... The key lines in expand.grid would seem to >> be >> >> if (!is.factor(x) && is.character(x)) x <- factor(x, >> levels = unique(x)) >> >> but I'm not sure why they are being converted to factors >> in the first place. WD> I think expand.grid converts input strings to factors so WD> they retain the order they have in the input. (Note WD> that the levels argument is unique(x), not the WD> sort(unique(x)) that data.frame uses.) People generally WD> give expand.grid sorted input and expect it to not alter WD> the order (the order of the levels affects tables and WD> and some plots). >> WD> lapply(expand.grid(Grade=c("Bad","Good","Better"),Size=c("Small","Medium WD> ","Large")), levels) $Grade [1] "Bad" "Good" "Better" WD> $Size [1] "Small" "Medium" "Large" >> WD> lapply(data.frame(Grade=c("Bad","Good","Better"),Size=c("Small","Medium" WD> ,"Large")), levels) $Grade [1] "Bad" "Better" "Good" WD> $Size [1] "Large" "Medium" "Small" WD> I have nothing against adding the stringsAsFactors WD> argument to expand.grid. That's fine, but I am VERY MUCH against making the default of that argument depend on the ominous default.stringsAsFactors() which is determined by getOption("stringsAsFactors"). Why would I hate such a change very much : Note that we have here an option which would change the result of a standard R (S) function expand.grid(). Whereas I already did not like that change when it happened for read.table(), in that case, one could at least say, that read.table() is in some way platform dependent {(because it typically depends on files of the local platform, but as we know this is not true even there; even now, if I tell my students, or a book author tells her readers to use read.table("http://.....") I can no longer be sure that my students get the same data frame, because they could have different settings of getOptions("stringsAsFactors") .... horrible, really!! )} Please, R should stay as much a functional language as possible and sensible! If we start having global options more and more influence the result of standard R functions, we are going down a very slippery rope, and one that is making R even more idionsyncratic than it already needs to be. Please, no !! Rather revert the read.table() default of "stringsAsFactors" to not depend on the option, and maybe provide another set of short forms of the various read.table(*, stringsAsFactors=FALSE) incantations such that all the factor-haters-string-lovers can use these short forms... At the very first DSC, 1999, Joe Eaton, author of GNU octave, told us how he regretted that he had started going down that bad path, because users had started asking for it. In the extreme case, we are ending up with a "language" that depends on a whole huge status setting, and what a given function computes can no longer be predicted by looking at the function calls, unless you simultaneously know that whole status. Please, No !! Martin Maechler, ETH Zurich WD> Bill Dunlap TIBCO Software Inc - Spotfire Division WD> wdunlap tibco.com WD> ______________________________________________ WD> R-devel at r-project.org mailing list WD> https://stat.ethz.ch/mailman/listinfo/r-devel From smckinney at bccrc.ca Mon Nov 17 22:00:17 2008 From: smckinney at bccrc.ca (smckinney at bccrc.ca) Date: Mon, 17 Nov 2008 22:00:17 +0100 (CET) Subject: [Rd] lines.formula() problem when data argument is missing (PR#13296) Message-ID: <20081117210017.415E2282EF48@mail.pubhealth.ku.dk> Full_Name: Steven McKinney Version: R 2.8.0 Patched svn rev 46845 OS: powerpc-apple-darwin9.5.0 Submission from: (NULL) (142.103.207.10) <> lines.formula() throws an error when subset argument is used but nothing is provided for data argument. Reproduce: x<-1:5 y<-c(1,3,NA,2,5) plot(y~x, type="n") # set up frame lines(y~x, subset=!is.na(y)) # works OK lines(y~x, type="o", col="blue") # works OK # but lines(y~x, subset=!is.na(y), col="red") # gives an error: This situation is handled appropriately by points.formula(). Following the coding style of points.formula() the proposed modifications would be lines.formula <- function (formula, data = parent.frame(), ..., subset) { m <- match.call(expand.dots = FALSE) if (is.matrix(eval(m$data, parent.frame()))) m$data <- as.data.frame(data) dots <- m$... dots <- lapply(dots, eval, data, parent.frame()) m$... <- NULL m[[1]] <- as.name("model.frame") m <- as.call(c(as.list(m), list(na.action = NULL))) mf <- eval(m, parent.frame()) if (!missing(subset)) { s <- eval(m$subset, data, parent.frame()) ###current ### l <- nrow(data) ###\current ###new (as per points.formula) if (!missing(data)) { l <- nrow(data) } else { mtmp <- m mtmp$subset <- NULL l <- nrow(eval(mtmp, parent.frame())) } ###\new dosub <- function(x) if (length(x) == l) x[s] else x ###current ### dots <- lapply(dots, dosub, s) ###\current ###new (as per points.formula) dots <- lapply(dots, dosub) ###\new } response <- attr(attr(mf, "terms"), "response") if (response) { varnames <- names(mf) y <- mf[[response]] if (length(varnames) > 2) stop("cannot handle more than one 'x' coordinate") xn <- varnames[-response] if (length(xn) == 0) do.call("lines", c(list(y), dots)) else do.call("lines", c(list(mf[[xn]], y), dots)) } else stop("must have a response variable") } Original report from R-help was: > -----Original Message----- > From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] > On Behalf Of John Field > Sent: Thursday, November 13, 2008 4:41 PM > To: r-help at r-project.org > Subject: [R] lines.formula with subset > > Dear list, > > When I try to use lines.formula with subset and another argument I > get an error. > e.g. > > x<-1:5 > y<-c(1,3,NA,2,5) > plot(y~x, type="n") # set up frame > lines(y~x, subset=!is.na(y)) # works OK > lines(y~x, type="o", col="blue") # works OK > # but > lines(y~x, subset=!is.na(y), col="red") # gives an error: > > Error in if (length(x) == l) x[s] else x : argument is of length zero > > Why does this happen? > It happens because the function graphics:::lines.formula tries to assess the number of rows of data in the data frame containing the variables in the formula y~x (see the line of code l <- nrow(data) in graphics:::lines.formula This is the 'el' in the 'length(x) == l' portion of the line you see in the error message) Because you did not provide the data frame, nrow(data) returns NULL, and thus the if() clause is 'length(x) == NULL' which yields answer logical(0), an invalid answer in an if() clause. Done this way, all is well: mydf <- data.frame(x = 1:5, y = c(1,3,NA,2,5)) plot(y~x, type="n", data = mydf) # set up frame lines(y~x, subset=!is.na(y), data = mydf) # works OK lines(y~x, type="o", col="blue", data = mydf) # works OK lines(y~x, subset=!is.na(y), col="red", data = mydf) # works OK The formula - based functions expect to see a dataframe object from the 'data' arg, but don't enforce this in this case. This may qualify as a logical bug in the graphics:::lines.formula function. An error should have been thrown before the if() clause evaluation, but I'm not sure where in the chain of function calls the check for a valid data object should be done and the error thrown. Otherwise, the data objects y and x that you set up should have been passed downwards in some fashion for evaluation. R-core members who know the rules better than I will have to determine how best to handle this one. HTH Steven McKinney Statistician Molecular Oncology and Breast Cancer Program British Columbia Cancer Research Centre email: smckinney at bccrc.ca tel: 604-675-8000 x7561 BCCRC Molecular Oncology 675 West 10th Ave, Floor 4 Vancouver B.C. V5Z 1L3 Canada > With thanks, > John > > ========================= > John Field Consulting Pty Ltd > 10 High Street, Burnside SA 5066 > Phone 08 8332 5294 or 0409 097 586 > Fax 08 8332 1229 > Email JohnField at ozemail.com.au > > ______________________________________________ > R-help at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting- > guide.html > and provide commented, minimal, self-contained, reproducible code. --please do not edit the information below-- Version: platform = powerpc-apple-darwin9.5.0 arch = powerpc os = darwin9.5.0 system = powerpc, darwin9.5.0 status = Patched major = 2 minor = 8.0 year = 2008 month = 11 day = 06 svn rev = 46845 language = R version.string = R version 2.8.0 Patched (2008-11-06 r46845) Locale: C Search Path: .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, package:datasets, package:methods, Autoloads, package:base From r.turner at auckland.ac.nz Mon Nov 17 20:49:21 2008 From: r.turner at auckland.ac.nz (Rolf Turner) Date: Tue, 18 Nov 2008 08:49:21 +1300 Subject: [Rd] assign("FALSE", TRUE) Message-ID: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> It was recently pointed out by Wacek Kusnierczyk that although one is prevented from doing FALSE <- TRUE one *can* do assign("FALSE",TRUE) and have an object named ``FALSE'' with value TRUE in one's workspace. This apparently has no deleterious effects; e.g. doing sample(1:7,replace=FALSE) gives a random permutation of 1:7 as expected and desired. I.e. the local object named ``FALSE'' is not used. Still, this seems counterintuitive and a bit confusing. Is it the intended state of affairs? I would have thought that FALSE <- and assign("FALSE",) would be completely equivalent. This is clearly not a very important issue, but it might bear some thinking about. cheers, Rolf Turner ###################################################################### Attention:\ This e-mail message is privileged and confid...{{dropped:9}} From maechler at stat.math.ethz.ch Mon Nov 17 23:11:36 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Mon, 17 Nov 2008 23:11:36 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> Message-ID: <18721.60440.551783.840625@cmath-5.math.ethz.ch> >>>>> "RT" == Rolf Turner >>>>> on Tue, 18 Nov 2008 08:49:21 +1300 writes: RT> It was recently pointed out by Wacek Kusnierczyk that RT> although one is prevented from doing RT> FALSE <- TRUE RT> one *can* do RT> assign("FALSE",TRUE) RT> and have an object named ``FALSE'' with value TRUE in RT> one's workspace. RT> This apparently has no deleterious effects; e.g. doing RT> sample(1:7,replace=FALSE) RT> gives a random permutation of 1:7 as expected and RT> desired. I.e. the local object named ``FALSE'' is not RT> used. RT> Still, this seems counterintuitive and a bit confusing. RT> Is it the intended state of affairs? I would have RT> thought that RT> FALSE <- RT> and RT> assign("FALSE",) RT> would be completely equivalent. Yes, such thoughts are understandable but wrong as you now know. Clearly assign("a b c", "abc") does work, but a b c <- "abc" does not; only `a b c` <- "abc" does, as well as `FALSE` <- TRUE .... and Wacek did mention the backticks. But in spite of all that I agree that I'd have liked `FALSE` <- to signal an error about the fact that it is a reserved word. RT> This is clearly not a very important issue, but it might RT> bear some thinking about. Yes. I'd propose that R-core look into how to make assignment to a reserved word an error. Thank you, Rolf, Martin From p.dalgaard at biostat.ku.dk Mon Nov 17 23:43:22 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Mon, 17 Nov 2008 23:43:22 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> Message-ID: <4921F38A.1080201@biostat.ku.dk> Rolf Turner wrote: > > It was recently pointed out by Wacek Kusnierczyk that although one is > prevented from doing > > FALSE <- TRUE > > one *can* do > > assign("FALSE",TRUE) > > and have an object named ``FALSE'' with value TRUE in one's workspace. > > This apparently has no deleterious effects; e.g. doing > > sample(1:7,replace=FALSE) > > gives a random permutation of 1:7 as expected and desired. I.e. the > local object named ``FALSE'' is not used. > > Still, this seems counterintuitive and a bit confusing. Is it the intended > state of affairs? I would have thought that > > FALSE <- > > and > > assign("FALSE",) > > would be completely equivalent. No, FALSE is a _keyword_ representing the logical value. > e <- quote(`FALSE` & FALSE) > e[[2]] `FALSE` > e[[3]] [1] FALSE > mode(e[[3]]) [1] "logical" > mode(e[[2]]) [1] "name" The thing that is equivalent to assign("FALSE",) is `FALSE`<-whatever. There are a couple of other keywords: TRUE, if, else, for, while, repeat, next, break, function. Did I forget any? The stuff you can do with FALSE isn't really any stranger than > `2` <- pi > 2+2 [1] 4 so that two and two remains four for any value of `2`. You can't do 2<-pi anymore than you can do FALSE<-foo. > > This is clearly not a very important issue, but it might bear some > thinking about. -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From p.dalgaard at biostat.ku.dk Tue Nov 18 00:00:40 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Tue, 18 Nov 2008 00:00:40 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <18721.60440.551783.840625@cmath-5.math.ethz.ch> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> Message-ID: <4921F798.6010006@biostat.ku.dk> Martin Maechler wrote: > But in spite of all that I agree that I'd have liked > `FALSE` <- > to signal an error about the fact that it is a reserved word. > > RT> This is clearly not a very important issue, but it might > RT> bear some thinking about. > > Yes. I'd propose that R-core look into how to make assignment to a > reserved word an error. I disagree. In a sense, this is the point of having the backtick operator: allowing you to work with names that would otherwise be syntax errors (notice that such names are sometimes created outside your control, e.g. via column names in data frames). If you start disallowing some of them again, well, that way lies madness! -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From h.wickham at gmail.com Tue Nov 18 02:24:25 2008 From: h.wickham at gmail.com (hadley wickham) Date: Mon, 17 Nov 2008 19:24:25 -0600 Subject: [Rd] checking for executable files ... WARNING Message-ID: In R 2.8. I get the following warning when checking my package: * checking for executable files ... WARNING Found the following executable file(s): .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 ... (for about 300 lines) I've tried putting .git in my .Rbuildignore, but this doesn't help the problem. Any ideas? Thanks, Hadley -- http://had.co.nz/ From bolker at ufl.edu Tue Nov 18 05:22:24 2008 From: bolker at ufl.edu (Ben Bolker) Date: Tue, 18 Nov 2008 04:22:24 +0000 (UTC) Subject: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292) References: <20081116000009.8029A2834615@mail.pubhealth.ku.dk> Message-ID: unb.br> writes: > > Full_Name: Reginaldo Constantino > Version: 2.8.0 > OS: Ubuntu Hardy (32 bit, kernel 2.6.24) > Submission from: (NULL) (189.61.88.2) > > For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is > obviously incorrect and inversely proportional to the number of replicates: > > > data(HairEyeColor) > > x <- margin.table(HairEyeColor, c(1, 2)) > > chisq.test(x,simulate.p.value=TRUE,B=2000) > Pearson's Chi-squared test with simulated p-value (based on 2000 > replicates) > data: x > X-squared = 138.2898, df = NA, p-value = 0.0004998 > > > chisq.test(x,simulate.p.value=TRUE,B=10000) > X-squared = 138.2898, df = NA, p-value = 1e-04 > > > chisq.test(x,simulate.p.value=TRUE,B=100000) > X-squared = 138.2898, df = NA, p-value = 1e-05 > > > chisq.test(x,simulate.p.value=TRUE,B=1000000) > X-squared = 138.2898, df = NA, p-value = 1e-06 > ... > > Also tested the same R version under Windows XP and got the same results. > Could you explain why this is wrong? The data are extremely unlikely under the null hypothesis (the standard chisq.test() gives p<2.2e-16), so the result of the simulation protocol is always 1/(B+1); that is, as is standard with these protocols, the observed value is added to the ensemble of simulations. Why is the p value "obviously incorrect"? cheers Ben Bolker From ripley at stats.ox.ac.uk Tue Nov 18 08:31:22 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 18 Nov 2008 07:31:22 +0000 (GMT) Subject: [Rd] checking for executable files ... WARNING In-Reply-To: References: Message-ID: On Mon, 17 Nov 2008, hadley wickham wrote: > In R 2.8. I get the following warning when checking my package: > > * checking for executable files ... WARNING > Found the following executable file(s): > .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 > .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 > .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 > .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 > ... (for about 300 lines) > > I've tried putting .git in my .Rbuildignore, but this doesn't help the > problem. Any ideas? Does 'R CMD build' a tarball and then 'R CMD check' not solve this? 'build' skips git files, and you only need to worry about executables in a tarball you ship. > > Thanks, > > Hadley > > -- > http://had.co.nz/ -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From kbarton at zbs.bialowieza.pl Tue Nov 18 01:55:09 2008 From: kbarton at zbs.bialowieza.pl (kbarton at zbs.bialowieza.pl) Date: Tue, 18 Nov 2008 01:55:09 +0100 (CET) Subject: [Rd] "deparse" with "nlines" argument produces empty elements (PR#13299) Message-ID: <20081118005509.2C63F282EF48@mail.pubhealth.ku.dk> Full_Name: Kamil Barto? Version: 2.8.0 OS: windows xp Submission from: (NULL) (212.33.92.187) According to the "deparse" function documentation "nlines" is the *maximum* number of lines to produce. But, when "nlines" argument is supplied, it produces exactly nlines of result, and the result contains empty elements at the end. Example: > deparse(quote(foo(1,2,3)), width.cutoff = 20, nlines=7) [1] "foo(1, 2, 3)" "" "" "" "" "" "" This behavior affects e.g. output of warnings() where "..." is attached to every call rather than only the truncated ones. > warnings() Warning messages: 1: In plot.window(...) ... : "na.action" is not a graphical parameter From r.turner at auckland.ac.nz Mon Nov 17 23:40:30 2008 From: r.turner at auckland.ac.nz (Rolf Turner) Date: Tue, 18 Nov 2008 11:40:30 +1300 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <18721.60440.551783.840625@cmath-5.math.ethz.ch> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> Message-ID: On 18/11/2008, at 11:11 AM, Martin Maechler wrote: > Yes. I'd propose that R-core look into how to make assignment to a > reserved word an error. That's good news. Thanks. cheers, Rolf Turner ###################################################################### Attention:\ This e-mail message is privileged and confid...{{dropped:9}} From h.wickham at gmail.com Tue Nov 18 13:57:41 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 18 Nov 2008 06:57:41 -0600 Subject: [Rd] checking for executable files ... WARNING In-Reply-To: References: Message-ID: On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley wrote: > On Mon, 17 Nov 2008, hadley wickham wrote: > >> In R 2.8. I get the following warning when checking my package: >> >> * checking for executable files ... WARNING >> Found the following executable file(s): >> .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 >> .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 >> .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 >> .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 >> ... (for about 300 lines) >> >> I've tried putting .git in my .Rbuildignore, but this doesn't help the >> problem. Any ideas? > > Does 'R CMD build' a tarball and then 'R CMD check' not solve this? > 'build' skips git files, and you only need to worry about executables in a > tarball you ship. Is this suggested best practice now? Hadley -- http://had.co.nz/ From ripley at stats.ox.ac.uk Tue Nov 18 14:00:50 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 18 Nov 2008 13:00:50 +0000 (GMT) Subject: [Rd] checking for executable files ... WARNING In-Reply-To: References: Message-ID: On Tue, 18 Nov 2008, hadley wickham wrote: > On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley > wrote: >> On Mon, 17 Nov 2008, hadley wickham wrote: >> >>> In R 2.8. I get the following warning when checking my package: >>> >>> * checking for executable files ... WARNING >>> Found the following executable file(s): >>> .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 >>> .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 >>> .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 >>> .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 >>> ... (for about 300 lines) >>> >>> I've tried putting .git in my .Rbuildignore, but this doesn't help the >>> problem. Any ideas? >> >> Does 'R CMD build' a tarball and then 'R CMD check' not solve this? >> 'build' skips git files, and you only need to worry about executables in a >> tarball you ship. > > Is this suggested best practice now? Always was, AFAIK. > > Hadley > > -- > http://had.co.nz/ > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From h.wickham at gmail.com Tue Nov 18 14:05:12 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 18 Nov 2008 07:05:12 -0600 Subject: [Rd] checking for executable files ... WARNING In-Reply-To: References: Message-ID: On Tue, Nov 18, 2008 at 7:00 AM, Prof Brian Ripley wrote: > On Tue, 18 Nov 2008, hadley wickham wrote: > >> On Tue, Nov 18, 2008 at 1:31 AM, Prof Brian Ripley >> wrote: >>> >>> On Mon, 17 Nov 2008, hadley wickham wrote: >>> >>>> In R 2.8. I get the following warning when checking my package: >>>> >>>> * checking for executable files ... WARNING >>>> Found the following executable file(s): >>>> .git/objects/00/12947a4bb4379fb0c3bed740314a9f4ac72331 >>>> .git/objects/00/21fac22a57a1567389ed34a9dc4f465c6cfd01 >>>> .git/objects/00/29da5c289489fdb2249e19f4b165ff5b37b3e6 >>>> .git/objects/00/36ad7f586eeac250e6609a1bf938e545101cb0 >>>> ... (for about 300 lines) >>>> >>>> I've tried putting .git in my .Rbuildignore, but this doesn't help the >>>> problem. Any ideas? >>> >>> Does 'R CMD build' a tarball and then 'R CMD check' not solve this? >>> 'build' skips git files, and you only need to worry about executables in >>> a >>> tarball you ship. >> >> Is this suggested best practice now? > > Always was, AFAIK. I might be useful to make this more explicit in "Writing R extensions". A sentence at the start of 1.3.1 "checking packages" would be helpful, as would removing this sentence from 1.3.2: "Run-time checks whether the package works correctly should be performed using R CMD check prior to invoking the build procedure." and strengthening the recommendation in this sentence: "It can be useful to run R CMD check --check-subdirs=yes on the built tarball as a final check on the contents." You didn't mention "--check-subdirs=yes" and I see from R CMD CHECK --help that yes is now the default, so perhaps that could be removed too. Hadley -- http://had.co.nz/ From maechler at stat.math.ethz.ch Tue Nov 18 14:14:49 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Tue, 18 Nov 2008 14:14:49 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <4921F798.6010006@biostat.ku.dk> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> <4921F798.6010006@biostat.ku.dk> Message-ID: <18722.49097.70529.650997@stat.math.ethz.ch> >>>>> "PD" == Peter Dalgaard >>>>> on Tue, 18 Nov 2008 00:00:40 +0100 writes: PD> Martin Maechler wrote: >> But in spite of all that I agree that I'd have liked >> `FALSE` <- to signal an error about the fact >> that it is a reserved word. >> RT> This is clearly not a very important issue, but it might RT> bear some thinking about. >> >> Yes. I'd propose that R-core look into how to make >> assignment to a reserved word an error. PD> I disagree. In a sense, this is the point of having the PD> backtick operator: allowing you to work with names that PD> would otherwise be syntax errors (notice that such names PD> are sometimes created outside your control, e.g. via PD> column names in data frames). If you start disallowing PD> some of them again, well, that way lies madness! No, no. I'm not against allowing names that are otherwise syntax errors. They were always possible via assign(). I just am convinced we should not allow reserved words. { S / S-plus does not either and gives a nice error message: S> assign("FALSE", TRUE) Problem: The name "FALSE" is reserved -- assignments to it are not allowed } Martin From P.Dalgaard at biostat.ku.dk Tue Nov 18 15:07:04 2008 From: P.Dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Tue, 18 Nov 2008 15:07:04 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <18722.49097.70529.650997@stat.math.ethz.ch> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> <4921F798.6010006@biostat.ku.dk> <18722.49097.70529.650997@stat.math.ethz.ch> Message-ID: <4922CC08.40301@biostat.ku.dk> Martin Maechler wrote: >>>>>> "PD" == Peter Dalgaard >>>>>> on Tue, 18 Nov 2008 00:00:40 +0100 writes: > > PD> Martin Maechler wrote: > >> But in spite of all that I agree that I'd have liked > >> `FALSE` <- to signal an error about the fact > >> that it is a reserved word. > >> > RT> This is clearly not a very important issue, but it might > RT> bear some thinking about. > >> > >> Yes. I'd propose that R-core look into how to make > >> assignment to a reserved word an error. > > PD> I disagree. In a sense, this is the point of having the > PD> backtick operator: allowing you to work with names that > PD> would otherwise be syntax errors (notice that such names > PD> are sometimes created outside your control, e.g. via > PD> column names in data frames). If you start disallowing > PD> some of them again, well, that way lies madness! > > No, no. I'm not against allowing names that are otherwise syntax > errors. They were always possible via assign(). > I just am convinced we should not allow reserved words. Please unconvince yourself then... You are solving a problem that isn't there: In R, you can assign to `FALSE` and access it as `FALSE`. You can not access it as FALSE because that is a keyword and you cannot assign to FALSE either. > { S / S-plus does not either and gives a nice error message: > > S> assign("FALSE", TRUE) > Problem: The name "FALSE" is reserved -- assignments to it are not allowed > } But FALSE is not a keyword in S. In R this would correspond to locking down F and T. There's another issue, namely that some keywords do have associated functions; e.g., `if` exists as a variable, and walls do come tumbling down if you redefine it (to a different function). However, that is a completely different thing, more related to redefining "+". (Incidentally, how hard would it be to ensure that such symbols were always looked up in the base namespace?). -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From ripley at stats.ox.ac.uk Tue Nov 18 15:33:50 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 18 Nov 2008 14:33:50 +0000 (GMT) Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <4922CC08.40301@biostat.ku.dk> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> <4921F798.6010006@biostat.ku.dk> <18722.49097.70529.650997@stat.math.ethz.ch> <4922CC08.40301@biostat.ku.dk> Message-ID: On Tue, 18 Nov 2008, Peter Dalgaard wrote: > Martin Maechler wrote: >>>>>>> "PD" == Peter Dalgaard >>>>>>> on Tue, 18 Nov 2008 00:00:40 +0100 writes: >> >> PD> Martin Maechler wrote: >> >> But in spite of all that I agree that I'd have liked >> >> `FALSE` <- to signal an error about the fact >> >> that it is a reserved word. >> >> >> RT> This is clearly not a very important issue, but it might >> RT> bear some thinking about. >> >> >> >> Yes. I'd propose that R-core look into how to make >> >> assignment to a reserved word an error. >> >> PD> I disagree. In a sense, this is the point of having the >> PD> backtick operator: allowing you to work with names that >> PD> would otherwise be syntax errors (notice that such names >> PD> are sometimes created outside your control, e.g. via >> PD> column names in data frames). If you start disallowing >> PD> some of them again, well, that way lies madness! >> >> No, no. I'm not against allowing names that are otherwise syntax >> errors. They were always possible via assign(). >> I just am convinced we should not allow reserved words. > > Please unconvince yourself then... You are solving a problem that isn't > there: In R, you can assign to `FALSE` and access it as `FALSE`. You can > not access it as FALSE because that is a keyword and you cannot assign > to FALSE either. > >> { S / S-plus does not either and gives a nice error message: >> >> S> assign("FALSE", TRUE) >> Problem: The name "FALSE" is reserved -- assignments to it are not allowed >> } > > But FALSE is not a keyword in S. In R this would correspond to locking > down F and T. I think both F and FALSE are 'keywords' in S, as that appears to say. > There's another issue, namely that some keywords do have associated > functions; e.g., `if` exists as a variable, and walls do come tumbling > down if you redefine it (to a different function). However, that is a > completely different thing, more related to redefining "+". > (Incidentally, how hard would it be to ensure that such symbols were > always looked up in the base namespace?). You mean they are primitives, so 'variable' for some meaning such as 'object'? The obvious idea is for the parser to do the lookup, but then the deparser would need to be altered. Otherwise the evaluator needs to special-case them, with a slight performance hit. > > -- > O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Tue Nov 18 16:58:22 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Tue, 18 Nov 2008 15:58:22 +0000 (GMT) Subject: [Rd] (PR#13299) "deparse" with "nlines" argument produces empty elements In-Reply-To: <20081118005509.2C63F282EF48@mail.pubhealth.ku.dk> References: <20081118005509.2C63F282EF48@mail.pubhealth.ku.dk> Message-ID: Although it does actually do what it is documented to do, producing the minimum necessary number of lines would be better, and I've altered R-patched to do so. Thank you for the report. Brian Ripley (who was in Bialowieza a couple of months ago). On Tue, 18 Nov 2008, kbarton at zbs.bialowieza.pl wrote: > Full_Name: Kamil Barto? > Version: 2.8.0 > OS: windows xp > Submission from: (NULL) (212.33.92.187) > > > According to the "deparse" function documentation "nlines" is the *maximum* > number of lines to produce. But, when "nlines" argument is supplied, it produces > exactly nlines of result, and the result contains empty elements at the end. > > Example: > >> deparse(quote(foo(1,2,3)), width.cutoff = 20, nlines=7) > [1] "foo(1, 2, 3)" "" "" "" "" > "" "" > > This behavior affects e.g. output of warnings() where "..." is attached to every > call rather than only the truncated ones. > >> warnings() > Warning messages: > 1: In plot.window(...) ... : "na.action" is not a graphical parameter > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From charlie.xia.fdu at gmail.com Tue Nov 18 20:50:51 2008 From: charlie.xia.fdu at gmail.com (charlie) Date: Tue, 18 Nov 2008 11:50:51 -0800 Subject: [Rd] Fwd: Fwd: SWIG with R and C++ STL In-Reply-To: <18720.62067.394678.969716@ron.nulle.part> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> <8ec76080811061129p2e54125eqee948a31bb4a4de8@mail.gmail.com> <11c6cf4e0811161910v25ce5f30r71e891673612c078@mail.gmail.com> <11c6cf4e0811161911y49ded77di905fc86ea630f4b5@mail.gmail.com> <18720.62067.394678.969716@ron.nulle.part> Message-ID: <11c6cf4e0811181150t7789aea6jf3a91c762e814ff9@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From armstrong.whit at gmail.com Tue Nov 18 21:02:01 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Tue, 18 Nov 2008 15:02:01 -0500 Subject: [Rd] Fwd: Fwd: SWIG with R and C++ STL In-Reply-To: <11c6cf4e0811181150t7789aea6jf3a91c762e814ff9@mail.gmail.com> References: <11c6cf4e0811041355v16321693hdd53d2376dc0a8c4@mail.gmail.com> <11c6cf4e0811061016r4dc114d8l261948c4512c1e12@mail.gmail.com> <8ec76080811061129p2e54125eqee948a31bb4a4de8@mail.gmail.com> <11c6cf4e0811161910v25ce5f30r71e891673612c078@mail.gmail.com> <11c6cf4e0811161911y49ded77di905fc86ea630f4b5@mail.gmail.com> <18720.62067.394678.969716@ron.nulle.part> <11c6cf4e0811181150t7789aea6jf3a91c762e814ff9@mail.gmail.com> Message-ID: <8ec76080811181202j214743a9y7f0d4c7e53cd46cd@mail.gmail.com> no all compilers support the export keyword. just put the template in a .h or .hpp file and include it in your .cpp file. that should be enough. -Whit On Tue, Nov 18, 2008 at 2:50 PM, charlie wrote: > Thanks guys for all your kind heartedness. > > Yeah, I got messed up with a lot of things in my previous program, like > missing the definition of one function and etc. I finally discovered a good > example on: > http://www.opensource.apple.com/darwinsource/Current/swig-4/swig/Examples/java/funcptr/index.html. > And I was able to make a workable example as following: > > /* test.i */ > %module test > %{ > #include "test.h" > %} > %include "test.h" > > %constant B (*F)( const A&)=f; > //let a=A(), b=B() > %template(ia) ex1; // from Doc, works > %template(jab) ex2; // jab(a,b) works > %template(kab) ex3; // kab(a,b,1) works > %template(lab) ex4; // lab(a,b,1,F) works > %template(fab) ex5; // fab(a,b,1,F) ultimate goal > > /* test.h */ > > #include > using namespace std; > > class A { }; > class B { }; > class E { }; > B f( const A& ) { cout<<"This is a function map A to B"< B); }; > typedef B (*fp)( const A& ); > > template E ex1(T a, T b) { cout<<"ex1, one parameter > template"< // NOTE: simple template function > > template E ex2(T t, S s) { cout<<"ex2, two parameters > template"< // NOTE: this extends the one above with two template parameters > > template E ex3(T t, S s, int k) { > cout<<"ex3, two parameters template plus an int argument"< *(new E); } > // NOTE: this extends the one above with additional integer argument > > template E ex4(T t, S s, int k, fp gp) { > cout<<"ex4, two parameters template, an int argument and an func ptr > argument"< A a=A(); B b=gp(a); return *(new E); } > // NOTE: this extends the one above with one more function poiter argument > > template E ex5(C c, D& d, int n, D (*g)(const C&)) { > cout<<"ex5, two parameters template, an int argument and a template func > ptr argument"< g(c); return *(new E); } > // NOTE: this temaplate function TF takes a template function poiter as > argument, our ultimate goal > > And currently I got my program work now. But the ex. in 5.4.9 still seems > not working. Anyway, so far good for me now. Maybe one last thing, currently > I need to put the definition and declaration of a template function all in > one file, otherwise I got undefined symbol error. How can I separate them > into a .h and .cpp file? The 'export' keyword which suggested in TCPL seems > do't work with gcc. Any comments? > > Thanks a bunch already! > > Charlie > > > > From armstrong.whit at gmail.com Tue Nov 18 23:07:04 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Tue, 18 Nov 2008 17:07:04 -0500 Subject: [Rd] anyone familiar with this error? Message-ID: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> [whit at linuxsvr R.packages]$ sudo R CMD INSTALL portfolio.construction * Installing to library '/usr/local/lib64/R/library' * Installing *source* package 'portfolio.construction' ... ** R ** preparing package for lazy loading Loading required package: fts Loading required package: quadprog Loading required package: Rexcelpoi terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct NULL not valid /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\", .libPaths()))); .getRequiredPackages(); tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" ) 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES= LC_ALL=C "${R_EXE}" --vanilla --slave ERROR: lazy loading failed for package 'portfolio.construction' ** Removing '/usr/local/lib64/R/library/portfolio.construction' ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction' [whit at linuxsvr R.packages]$ I've tried a few things, but can't seem to track down the problem. it's leaving core files in my package directory. (not in the .Rcheck directory, directly in the package dir) Thanks, Whit From ggellner at uoguelph.ca Tue Nov 18 23:24:27 2008 From: ggellner at uoguelph.ca (Gabriel Gellner) Date: Tue, 18 Nov 2008 17:24:27 -0500 Subject: [Rd] R license: GPL v2 or v3? Message-ID: <20081118222427.GA18649@encolpuis> For a project I am porting some of R's source code, and I want to get the license for my project correct, but the top level COPYING file for R's source states GPL v2, but when using: > license() (which also states GPL version 2) points me towards: > RShowDoc('COPYING') which states GPL v3. Which is correct? Thanks for clarification (and the amazing amount of code!). Gabriel From ggrothendieck at gmail.com Wed Nov 19 00:31:51 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Tue, 18 Nov 2008 18:31:51 -0500 Subject: [Rd] anyone familiar with this error? In-Reply-To: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> References: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> Message-ID: <971536df0811181531m1a000bfw10e99b28e63baf78@mail.gmail.com> Don't really know but you could see if the info in Avoiding R Bugs section on the http:/r-proto.googlecode.com page applies, particularly the first point on Lazy Loading. On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong wrote: > [whit at linuxsvr R.packages]$ sudo R CMD INSTALL portfolio.construction > * Installing to library '/usr/local/lib64/R/library' > * Installing *source* package 'portfolio.construction' ... > ** R > ** preparing package for lazy loading > Loading required package: fts > Loading required package: quadprog > Loading required package: Rexcelpoi > terminate called after throwing an instance of 'std::logic_error' > what(): basic_string::_S_construct NULL not valid > /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done > ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\", > .libPaths()))); .getRequiredPackages(); > tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" ) > 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES= > LC_ALL=C "${R_EXE}" --vanilla --slave > ERROR: lazy loading failed for package 'portfolio.construction' > ** Removing '/usr/local/lib64/R/library/portfolio.construction' > ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction' > [whit at linuxsvr R.packages]$ > > > I've tried a few things, but can't seem to track down the problem. > > it's leaving core files in my package directory. (not in the .Rcheck > directory, directly in the package dir) > > Thanks, > Whit > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From ggrothendieck at gmail.com Wed Nov 19 00:32:23 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Tue, 18 Nov 2008 18:32:23 -0500 Subject: [Rd] anyone familiar with this error? In-Reply-To: <971536df0811181531m1a000bfw10e99b28e63baf78@mail.gmail.com> References: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> <971536df0811181531m1a000bfw10e99b28e63baf78@mail.gmail.com> Message-ID: <971536df0811181532t5d5b67a2q9e35754ee9da53ae@mail.gmail.com> There was a slash missing. It should be http://r-proto.googlecode.com On Tue, Nov 18, 2008 at 6:31 PM, Gabor Grothendieck wrote: > Don't really know but you could see if the info in Avoiding R Bugs > section on the http:/r-proto.googlecode.com page applies, particularly > the first point on Lazy Loading. > > On Tue, Nov 18, 2008 at 5:07 PM, Whit Armstrong > wrote: >> [whit at linuxsvr R.packages]$ sudo R CMD INSTALL portfolio.construction >> * Installing to library '/usr/local/lib64/R/library' >> * Installing *source* package 'portfolio.construction' ... >> ** R >> ** preparing package for lazy loading >> Loading required package: fts >> Loading required package: quadprog >> Loading required package: Rexcelpoi >> terminate called after throwing an instance of 'std::logic_error' >> what(): basic_string::_S_construct NULL not valid >> /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done >> ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\", >> .libPaths()))); .getRequiredPackages(); >> tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" ) >> 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES= >> LC_ALL=C "${R_EXE}" --vanilla --slave >> ERROR: lazy loading failed for package 'portfolio.construction' >> ** Removing '/usr/local/lib64/R/library/portfolio.construction' >> ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction' >> [whit at linuxsvr R.packages]$ >> >> >> I've tried a few things, but can't seem to track down the problem. >> >> it's leaving core files in my package directory. (not in the .Rcheck >> directory, directly in the package dir) >> >> Thanks, >> Whit >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From mtmorgan at fhcrc.org Wed Nov 19 04:52:27 2008 From: mtmorgan at fhcrc.org (Martin Morgan) Date: Tue, 18 Nov 2008 19:52:27 -0800 Subject: [Rd] more efficient small subsets from moderate vectors? Message-ID: <6phk5b0cqys.fsf@gopher4.fhcrc.org> This creates a named vector of length nx, then repeatedly draws a single sample from it. lkup <- function(nx, m=10000L) { tbl <- seq_len(nx) names(tbl) <- as.character(tbl) v <- sample(names(tbl), m, replace=TRUE) system.time(for(k in v) tbl[k], gcFirst=TRUE) } There is an abrupt performance degredation at nx=1000 > lkup(1000) user system elapsed 0.180 0.000 0.179 > lkup(1001) user system elapsed 2.444 0.016 2.462 This is because of the heuristic at stringSubscript.c:424, which switches from a 'naive' nx * ns algorithm (ns is the number of elements to be extracted, ns = 1 above) to a hash-based strategy when nx * ns > 1. It seems like the 'naive' algorithm takes nx * ns time, whereas the hash-based algorithm takes C(nx) + ns, where C(nx) is the cost of creating the hash. Guessing that the cost of building the hash is about linear in nx, the results above suggest a new heuristic for switching at ns of about 15. (I don't quite follow the last sentence of the comment above stringSubscript, so perhaps I misunderstand entirely). Martin > sessionInfo() R version 2.9.0 Under development (unstable) (2008-11-15 r46953) i686-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 From ripley at stats.ox.ac.uk Wed Nov 19 07:31:07 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 06:31:07 +0000 (GMT) Subject: [Rd] anyone familiar with this error? In-Reply-To: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> References: <8ec76080811181407o6dc6b392q68a8948a7cf534e6@mail.gmail.com> Message-ID: On Tue, 18 Nov 2008, Whit Armstrong wrote: > [whit at linuxsvr R.packages]$ sudo R CMD INSTALL portfolio.construction > * Installing to library '/usr/local/lib64/R/library' > * Installing *source* package 'portfolio.construction' ... > ** R > ** preparing package for lazy loading > Loading required package: fts > Loading required package: quadprog > Loading required package: Rexcelpoi > terminate called after throwing an instance of 'std::logic_error' > what(): basic_string::_S_construct NULL not valid > /usr/local/lib64/R/bin/INSTALL: line 455: 25001 Done > ( echo "options(warn=1); invisible(.libPaths(c(\"${lib}\", > .libPaths()))); .getRequiredPackages(); > tools:::makeLazyLoading(\"${R_PACKAGE_NAME}\", \"${lib}\")" ) > 25002 Aborted (core dumped) | R_DEFAULT_PACKAGES= > LC_ALL=C "${R_EXE}" --vanilla --slave > ERROR: lazy loading failed for package 'portfolio.construction' > ** Removing '/usr/local/lib64/R/library/portfolio.construction' > ** Restoring previous '/usr/local/lib64/R/library/portfolio.construction' > [whit at linuxsvr R.packages]$ > > > I've tried a few things, but can't seem to track down the problem. > > it's leaving core files in my package directory. (not in the .Rcheck > directory, directly in the package dir) Well, you did INSTALL, not 'check', so there is no .Rcheck directory. The issue is that it cannot load your package, and it seems the error is in C++ code in the package or a dependency. You've given use very little to go on beyond that. -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Wed Nov 19 07:36:26 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 06:36:26 +0000 (GMT) Subject: [Rd] R license: GPL v2 or v3? In-Reply-To: <20081118222427.GA18649@encolpuis> References: <20081118222427.GA18649@encolpuis> Message-ID: On Tue, 18 Nov 2008, Gabriel Gellner wrote: > For a project I am porting some of R's source code, and I want to > get the license for my project correct, but the top level COPYING file > for R's source states GPL v2, but when using: > > > license() > > (which also states GPL version 2) points me towards: > > > RShowDoc('COPYING') > > which states GPL v3. Which is correct? It does not, at least in R 2.8.0 (and I am pretty sure in no version of R). What exactly are you looking at? Many files in R are licensed under GPL 2 or later, but not all. All non-trivial source files should have a header giving the licence terms for that file. > > Thanks for clarification (and the amazing amount of code!). > > Gabriel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ripley at stats.ox.ac.uk Wed Nov 19 07:43:07 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 06:43:07 +0000 (GMT) Subject: [Rd] more efficient small subsets from moderate vectors? In-Reply-To: <6phk5b0cqys.fsf@gopher4.fhcrc.org> References: <6phk5b0cqys.fsf@gopher4.fhcrc.org> Message-ID: Note that you are talking about very small times here. Yes, it probably switches early for ns=1, but is that a common usage? Do people really do lots of single lookups from long vectors -- if so they deserve what they get, and it would be better to use a hashed environment. (Indeed a strategy considered but not implemented was to attach a hash for future use.) On Tue, 18 Nov 2008, Martin Morgan wrote: > This creates a named vector of length nx, then repeatedly draws a > single sample from it. > > lkup <- function(nx, m=10000L) { > tbl <- seq_len(nx) > names(tbl) <- as.character(tbl) > v <- sample(names(tbl), m, replace=TRUE) > system.time(for(k in v) tbl[k], gcFirst=TRUE) > } > > There is an abrupt performance degredation at nx=1000 > >> lkup(1000) > user system elapsed > 0.180 0.000 0.179 >> lkup(1001) > user system elapsed > 2.444 0.016 2.462 > > This is because of the heuristic at stringSubscript.c:424, which > switches from a 'naive' nx * ns algorithm (ns is the number of > elements to be extracted, ns = 1 above) to a hash-based strategy when > nx * ns > 1. > > It seems like the 'naive' algorithm takes nx * ns time, whereas the > hash-based algorithm takes C(nx) + ns, where C(nx) is the cost of > creating the hash. Guessing that the cost of building the hash is > about linear in nx, the results above suggest a new heuristic for > switching at ns of about 15. > > (I don't quite follow the last sentence of the comment above > stringSubscript, so perhaps I misunderstand entirely). > > Martin > >> sessionInfo() > R version 2.9.0 Under development (unstable) (2008-11-15 r46953) > i686-pc-linux-gnu > > locale: > LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > -- > Martin Morgan > Computational Biology / Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N. > PO Box 19024 Seattle, WA 98109 > > Location: Arnold Building M2 B169 > Phone: (206) 667-2793 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From maechler at stat.math.ethz.ch Wed Nov 19 10:37:39 2008 From: maechler at stat.math.ethz.ch (Martin Maechler) Date: Wed, 19 Nov 2008 10:37:39 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <4922CC08.40301@biostat.ku.dk> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> <4921F798.6010006@biostat.ku.dk> <18722.49097.70529.650997@stat.math.ethz.ch> <4922CC08.40301@biostat.ku.dk> Message-ID: <18723.56931.862548.444327@stat.math.ethz.ch> >>>>> "PD" == Peter Dalgaard >>>>> on Tue, 18 Nov 2008 15:07:04 +0100 writes: PD> Martin Maechler wrote: >>>>>>> "PD" == Peter Dalgaard on >>>>>>> Tue, 18 Nov 2008 00:00:40 +0100 writes: PD> Martin Maechler wrote: >> >> But in spite of all that I agree that I'd have liked >> >> `FALSE` <- to signal an error about the >> >> fact that it is a reserved word. RT> This is clearly not a very important issue, but it might RT> bear some thinking about. >> >> Yes. I'd propose that R-core look into how to make >> >> assignment to a reserved word an error. PD> I disagree. In a sense, this is the point of having the PD> backtick operator: allowing you to work with names that PD> would otherwise be syntax errors (notice that such names PD> are sometimes created outside your control, e.g. via PD> column names in data frames). If you start disallowing PD> some of them again, well, that way lies madness! >> No, no. I'm not against allowing names that are otherwise >> syntax errors. They were always possible via assign(). >> I just am convinced we should not allow reserved words. PD> Please unconvince yourself then... You are solving a PD> problem that isn't there: In R, you can assign to PD> `FALSE` and access it as `FALSE`. You can not access it PD> as FALSE because that is a keyword and you cannot assign PD> to FALSE either. I now have been "unconvinced", ((so the following is just some clarification ...)) but notably not mainly by the above. I'd consider the backtick operator as -- very nice -- syntactic sugar for assign() and get(). And, for "normal" identifiers, foo <- 1 `foo` <- 1 assign("foo", 1) and foo `foo` get("foo") are each three-fold equivalent. If a user does not *know* about keywords/reserved words, (s)he can get a bit confused by how e.g. break or `break` e.g. are handled: Recall that Joe Average User does not know about assign, get, `..` etc, but does know about ls() and typing an object name: If he does ls(), sees "break" (which stems from previous assign("break", 3) or `break` <- 3) and then types > break or > str(break) into the R console to inspect the variable he has "seen" in ls(), the result will be a bit confusing to such a user, and I had wanted that we'd evade that confusion. The example with FALSE or `FALSE` is different but with similar potential confusion. >> { S / S-plus does not either and gives a nice error >> message: >> S> assign("FALSE", TRUE) >> Problem: The name "FALSE" is reserved -- assignments to >> it are not allowed } PD> But FALSE is not a keyword in S. In R this would PD> correspond to locking down F and T. Hmm,... maybe. Brian has already answered to that. Martin PD> There's another issue, namely that some keywords do have PD> associated functions; e.g., `if` exists as a variable, PD> and walls do come tumbling down if you redefine it (to a PD> different function). However, that is a completely PD> different thing, more related to redefining "+". PD> (Incidentally, how hard would it be to ensure that such PD> symbols were always looked up in the base namespace?). PD> -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B PD> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 PD> Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: PD> (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) PD> FAX: (+45) 35327907 PD> ______________________________________________ PD> R-devel at r-project.org mailing list PD> https://stat.ethz.ch/mailman/listinfo/r-devel From ripley at stats.ox.ac.uk Wed Nov 19 11:24:58 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 10:24:58 +0000 (GMT) Subject: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7") In-Reply-To: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> References: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> Message-ID: I can't actually check what happens since the message has been garbled en route to me. Can you please send what you intended using \uxxxx escapes so it is portable. (What I have is what appears to be UTF-8 re-encoded in UTF-8, things like c3 84 3f.) And can you also confirm that the example works correctly directly in pdf()? On Fri, 31 Oct 2008, zemlys at gmail.com wrote: > Hi, > > Sweave for some reason does not respect encoding setting in pdf.options. Rather it uses its own setting. I think you need to set option pdf.encoding="ISOLatin7" on the Sweave call. It would probably be better if Sweave() fetched the default for options$pdf.encoding from pdf.options(), and definitely that this was documented. > Everything is OK with ps.options. Thus when using non-default encoding > for graphs, resulting graphics eps file is correct, but pdf file is > not. Workaround is very simple, just use latex->dvips->ps2pdf chain to > get the intended pdf document. I tried to find the explanation for this, > but I did not find anything. If this is documented behaviour, I am sorry > for the disturbance. > > After Sweaving the file below, pdflatex and latex->dvips->ps2pdf will > produce different pdfs. The tex file compiled succesfully in Ubuntu > 8.04, and TeXLive 2007. > > Sincerely yours, > > Vaidotas Zemlys > > test.Rnw file: > > \documentclass[a4paper]{article} > \usepackage[utf8x]{inputenc} > \usepackage[T1]{fontenc} > > \title{Problem with pdf.options} > \author{Vaidotas Zemlys} > > \begin{document} > \maketitle > > Note the Lithuanian letters in latex will not display correctly, you > need > additional package. This does not matter to R, since we use Unicode and > pass the > correct encoding. > > \begin{center} > <>= > pdf.options(enc="ISOLatin7") > ps.options(enc="ISOLatin7") > plot(rnorm(100),main="??????????????????") > @ > \end{center} > > \end{document} > > > > > --please do not edit the information below-- > > Version: > platform = i486-pc-linux-gnu > arch = i486 > os = linux-gnu > system = i486, linux-gnu > status = > major = 2 > minor = 8.0 > year = 2008 > month = 10 > day = 20 > svn rev = 46754 > language = R > version.string = R version 2.8.0 (2008-10-20) > > Locale: > LC_CTYPE=fr_FR.UTF-8 at euro;LC_NUMERIC=C;LC_TIME=fr_FR.UTF-8 at euro;LC_COLLATE=fr_FR.UTF-8 at euro;LC_MONETARY=C;LC_MESSAGES=fr_FR.UTF-8 at euro;LC_PAPER=fr_FR.UTF-8 at euro;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=fr_FR.UTF-8 at euro;LC_IDENTIFICATION=C > > Search Path: > .GlobalEnv, package:stats, package:graphics, package:grDevices, > package:utils, package:datasets, package:methods, Autoloads, > package:base > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ggrothendieck at gmail.com Wed Nov 19 13:15:03 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Wed, 19 Nov 2008 07:15:03 -0500 Subject: [Rd] R license: GPL v2 or v3? In-Reply-To: <20081118222427.GA18649@encolpuis> References: <20081118222427.GA18649@encolpuis> Message-ID: <971536df0811190415r71846e0ex976b00f9727a72a4@mail.gmail.com> There is an analysis of the R license here: http://www.ohloh.net/projects/rproject/analyses/latest On Tue, Nov 18, 2008 at 5:24 PM, Gabriel Gellner wrote: > For a project I am porting some of R's source code, and I want to > get the license for my project correct, but the top level COPYING file > for R's source states GPL v2, but when using: > > > license() > > (which also states GPL version 2) points me towards: > > > RShowDoc('COPYING') > > which states GPL v3. Which is correct? > > Thanks for clarification (and the amazing amount of code!). > > Gabriel > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From Waclaw.Marcin.Kusnierczyk at idi.ntnu.no Wed Nov 19 13:24:26 2008 From: Waclaw.Marcin.Kusnierczyk at idi.ntnu.no (Wacek Kusnierczyk) Date: Wed, 19 Nov 2008 13:24:26 +0100 Subject: [Rd] assign("FALSE", TRUE) In-Reply-To: <18723.56931.862548.444327@stat.math.ethz.ch> References: <3EFAB5FA-61AF-4646-8C17-288838AB075B@auckland.ac.nz> <18721.60440.551783.840625@cmath-5.math.ethz.ch> <4921F798.6010006@biostat.ku.dk> <18722.49097.70529.650997@stat.math.ethz.ch> <4922CC08.40301@biostat.ku.dk> <18723.56931.862548.444327@stat.math.ethz.ch> Message-ID: <4924057A.3040707@idi.ntnu.no> Martin Maechler wrote: > but notably not mainly by the above. I'd consider the backtick > operator as -- very nice -- syntactic sugar for > assign() and get(). > > And, for "normal" identifiers, > > foo <- 1 > `foo` <- 1 > assign("foo", 1) > "foo" <- 1 # same effect as above > and > foo > `foo` > get("foo") > "foo" # not 1? (that is to say, i find this a tiny little bit incoherent, but perhaps useful for assignments, as " is easier to get from my keyboard than `) > are each three-fold equivalent. If a user does not *know* about > keywords/reserved words, (s)he can get a bit confused by > how e.g. break or `break` e.g. are handled: > Recall that Joe Average User does not know about assign, get, > `..` etc, but does know about ls() and typing an object name: > If he does ls(), sees "break" (which stems from previous > assign("break", 3) or `break` <- 3) > and then types > > break > or > > str(break) > btw. i find the following sequence of error messages a tiny little bit confusing: break(1) # Error: no loop to break from, jumping to top level "break" = function(arg) arg break(1) # Error in break : argument "arg" is missing, with no default "break" = function(arg=1) arg break(1) # Error: attempt to apply non-function "if" = function(arg) arg if(1) # keeps waiting for more input if(1) 2 # Error in if (1) 2 : unused argument(s) (2) vQ From bolker at ufl.edu Wed Nov 19 14:22:16 2008 From: bolker at ufl.edu (Ben Bolker) Date: Wed, 19 Nov 2008 13:22:16 +0000 (UTC) Subject: [Rd] chisq.test with simulate.p.value=TRUE (PR#13292) References: <20081116000009.8029A2834615@mail.pubhealth.ku.dk> Message-ID: unb.br> writes: > For many tables, chisq.test with simulate.p.value=TRUE gives a p value that is > obviously incorrect and inversely proportional to the number of replicates: > > > data(HairEyeColor) > > x <- margin.table(HairEyeColor, c(1, 2)) > > chisq.test(x,simulate.p.value=TRUE,B=2000) > Pearson's Chi-squared test with simulated p-value (based on 2000 > replicates) > data: x > X-squared = 138.2898, df = NA, p-value = 0.0004998 > > > chisq.test(x,simulate.p.value=TRUE,B=10000) > X-squared = 138.2898, df = NA, p-value = 1e-04 > > > chisq.test(x,simulate.p.value=TRUE,B=100000) > X-squared = 138.2898, df = NA, p-value = 1e-05 > > > chisq.test(x,simulate.p.value=TRUE,B=1000000) > X-squared = 138.2898, df = NA, p-value = 1e-06 > ... > Tried to answer this the other day but the answer must have gotten lost. The standard analytical chi-squared test here gives p<2.2e-16 (i.e. very very small). The values given above, up to limited display of significant digits, are precisely 1/(B+1); that is, the simulated chi-squared values are never less than the observed chi-squared statistic (the observed value itself is included in the ensemble, so the p-value is given as 1/(B+1) rather that <1/B; you can read about the reasons for this elsewhere [?]). Bottom line: why do you think these results are "obviously incorrect"? Ben Bolker From Benjamin.Hofner at imbe.med.uni-erlangen.de Tue Nov 18 14:30:36 2008 From: Benjamin.Hofner at imbe.med.uni-erlangen.de (Benjamin Hofner) Date: Tue, 18 Nov 2008 14:30:36 +0100 Subject: [Rd] Wishlist - better object.size() function Message-ID: <4922C37C.7080301@imbe.med.uni-erlangen.de> Some time ago I came across the function object.size() to estimate the size of an R object. I don't know if the behavior of the function is intended to be quite "user unfriendly" as it is right now or if just nobody was thinking/caring about it. I have two suggestions to improve it: - Why is it named object.size() and not just size()? The latter would be far more intuitive and shorter and as far as I know there is no other function size (in the base distribution). - Why is the function returning the size in bytes? This is (in most cases) overly accurate and for humans hard to read. I would suggest to have it printed in mb per default and additionally add a switch to choose the appropriate unit. This is a first proposal: size <- function(x, type=c("mb","byte","kb","gb"), digits=3){ type <- match.arg(type) RET <- switch(type, byte = object.size(x), kb = object.size(x)/1024, mb = object.size(x)/(1024^2), gb = object.size(x)/(1024^3)) cat(round(RET,digits), type, "\n") invisible(RET) } I think this would improve the usability of the function a lot. Thanks, Benjamin -- ****************************************************************************** Dipl.-Stat. Benjamin Hofner Institut f?r Medizininformatik, Biometrie und Epidemiologie Friedrich-Alexander-Universit?t Erlangen-N?rnberg Waldstr. 6 - 91054 Erlangen - Germany Tel: +49-9131-85-22707 Fax: +49-9131-85-25740 http://www.imbe.med.uni-erlangen.de/~hofnerb/ http://www.benjaminhofner.de ****************************************************************************** From zemlys at gmail.com Wed Nov 19 12:45:24 2008 From: zemlys at gmail.com (Vaidotas Zemlys) Date: Wed, 19 Nov 2008 13:45:24 +0200 Subject: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7") In-Reply-To: References: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> Message-ID: 2008/11/19 Prof Brian Ripley : > I can't actually check what happens since the message has been garbled en > route to me. Can you please send what you intended using \uxxxx escapes so > it is portable. (What I have is what appears to be UTF-8 re-encoded in > UTF-8, things like c3 84 3f.) > > And can you also confirm that the example works correctly directly in pdf()? OK, the modified R code is: plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") It does not work correctly with Sweave, as I wrote in my email, I rechecked. And yes it works if only pdf is used. > On Fri, 31 Oct 2008, zemlys at gmail.com wrote: > >> Hi, >> >> Sweave for some reason does not respect encoding setting in pdf.options. > > Rather it uses its own setting. I think you need to set option > pdf.encoding="ISOLatin7" on the Sweave call. Is it possible to do that? Sweave function in R, does not support that, and using SweaveHooks produced the same result. > > It would probably be better if Sweave() fetched the default for > options$pdf.encoding from pdf.options(), and definitely that this was > documented. I did not find any mention about encodings in ?Sweave, ?RweaveLatex and ?Rtangle, and Sweave manual and FAQ. I looked at the code of RweaveLatexSetup, and saw that pdf.encoding is defined explicitly, that is how I figured out, that probably eps files are probably ok. Sorry for the garbled message, next time I will send unicode portable code without relying on email encodings. Sincerely yours, Vaidotas Zemlys From ripley at stats.ox.ac.uk Wed Nov 19 15:09:05 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 14:09:05 +0000 (GMT) Subject: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7") In-Reply-To: References: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> Message-ID: On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: > 2008/11/19 Prof Brian Ripley : >> I can't actually check what happens since the message has been garbled en >> route to me. Can you please send what you intended using \uxxxx escapes so >> it is portable. (What I have is what appears to be UTF-8 re-encoded in >> UTF-8, things like c3 84 3f.) >> >> And can you also confirm that the example works correctly directly in pdf()? > > OK, the modified R code is: > > plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") > > It does not work correctly with Sweave, as I wrote in my email, I > rechecked. And yes it works if only pdf is used. It works for me in xpdf, but not Acroread 8.1.3. >> On Fri, 31 Oct 2008, zemlys at gmail.com wrote: >> >>> Hi, >>> >>> Sweave for some reason does not respect encoding setting in pdf.options. >> >> Rather it uses its own setting. I think you need to set option >> pdf.encoding="ISOLatin7" on the Sweave call. > > Is it possible to do that? Sweave function in R, does not support > that, and using > SweaveHooks produced the same result. So it is not recognizing the option, it seems: Yes, RweaveLatexSetup does not know about it. >> It would probably be better if Sweave() fetched the default for >> options$pdf.encoding from pdf.options(), and definitely that this was >> documented. > > I did not find any mention about encodings in ?Sweave, ?RweaveLatex > and ?Rtangle, and Sweave manual and FAQ. Yes, Sweave is supposedly frozen pending unbundling. Note that this does work (at least for me) in lt_LT.utf8: it is because you were in fr_FR.utf8 that you had a problem. So I think the solution is actually pretty simple: use the correct locale. I've changed R-patched to take the defaults from pdf.options(), but Sweave should still be able to set them. > I looked at the code of RweaveLatexSetup, and saw that pdf.encoding is > defined explicitly, that is how I figured out, that > probably eps files are probably ok. > > Sorry for the garbled message, next time I will send unicode portable > code without relying on email encodings. > > Sincerely yours, > > Vaidotas Zemlys > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From dkor at northwestern.edu Wed Nov 19 17:55:59 2008 From: dkor at northwestern.edu (Daniel Kornhauser) Date: Wed, 19 Nov 2008 10:55:59 -0600 Subject: [Rd] Buggy trellis.focus() with xyplot ? Message-ID: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From gregor.gorjanc at bfro.uni-lj.si Wed Nov 19 18:49:43 2008 From: gregor.gorjanc at bfro.uni-lj.si (Gregor Gorjanc) Date: Wed, 19 Nov 2008 17:49:43 +0000 (UTC) Subject: [Rd] Wishlist - better object.size() function References: <4922C37C.7080301@imbe.med.uni-erlangen.de> Message-ID: Benjamin Hofner imbe.med.uni-erlangen.de> writes: ... > - Why is the function returning the size in bytes? This is (in most > cases) overly accurate and for humans hard to read. I would suggest to > have it printed in mb per default and additionally add a switch to > choose the appropriate unit. > > This is a first proposal: ... There was a such proposal some time ago. See https://stat.ethz.ch/pipermail/r-devel/2006-August/038935.html https://stat.ethz.ch/pipermail/r-devel/2006-September/042673.html http://tolstoy.newcastle.edu.au/R/e2/devel/06/09/0181.html Unfortunatelly, there was no interest in adding this to R. I removed the files mentioned in above posts. However, the proposed implementation was added to my "private-playground" package ggmisc. The package can be downloaded at http://gregor.gorjanc.googlepages.com/ggmisc_0.2.1.tar.gz http://gregor.gorjanc.googlepages.com/ggmisc_0.2.1.zip gg From jhallman at frb.gov Wed Nov 19 19:33:20 2008 From: jhallman at frb.gov (Jeffrey J. Hallman) Date: Wed, 19 Nov 2008 13:33:20 -0500 Subject: [Rd] configure.vars arg needed for install.packages Message-ID: Currently, install.packages takes a 'configure.args' argument that adds a --configure-args to the eventual call to R CMD INSTALL. It does not, however, have a 'configure.vars' argument to similarly add the --configure-vars option to R CMD INSTALL, which seems to be an oversight. -- Jeff From ripley at stats.ox.ac.uk Wed Nov 19 19:33:56 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 18:33:56 +0000 Subject: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7") In-Reply-To: References: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> Message-ID: <49245C14.8080909@stats.ox.ac.uk> Just to close the loop on this, the following works in en_GB.utf8 on 2.8.0: <>= pdf.options(enc="ISOLatin7") ps.options(enc="ISOLatin7") plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") @ I think the point is that you can use different encodings for different figures in one Sweave document. But in R-devel you can now pass any option via the Sweave() call as I at least expected from the documentation. Vaidotas Zemlys wrote: > 2008/11/19 Prof Brian Ripley : >> On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: >> >>> OK, the modified R code is: >>> >>> >>> plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") >>> >>> It does not work correctly with Sweave, as I wrote in my email, I >>> rechecked. And yes it works if only pdf is used. >> It works for me in xpdf, but not Acroread 8.1.3. > > Yes, I checked only with evince, and assumed, that Acroread will be > similar. Acrobat 9 (on windows) shows the letters, but they are > bunched up together. Changing the default family to URWHelvetica did > not help either. So that rules out using pdf for me. > >>> I did not find any mention about encodings in ?Sweave, ?RweaveLatex >>> and ?Rtangle, and Sweave manual and FAQ. >> Yes, Sweave is supposedly frozen pending unbundling. >> >> Note that this does work (at least for me) in lt_LT.utf8: it is because you >> were in fr_FR.utf8 that you had a problem. >> >> So I think the solution is actually pretty simple: use the correct locale. >> I've changed R-patched to take the defaults from pdf.options(), but Sweave >> should still be able to set them. >> > > Aah, this does not occured to me. I thought that because locale is > unicode it should not matter which unicode letters I use. That is a > not correct assumption. > > Thank you for your answers, > > > Vaidotas Zemlys -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From plroebuck at mdanderson.org Wed Nov 19 20:19:25 2008 From: plroebuck at mdanderson.org (Paul Roebuck) Date: Wed, 19 Nov 2008 13:19:25 -0600 (CST) Subject: [Rd] doc buglet / attr method Message-ID: Under Value section for attr: For the extractor, the value of the attribute matched, or \code{NULL} if no exact match is found and no or more ^^^^^^^^^^ than one partial match is found. R version 2.7.2 (2008-08-25) -- and -- ---------------------------------------------------------- SIGSIG -- signature too long (core dumped) From dkor at northwestern.edu Wed Nov 19 20:59:29 2008 From: dkor at northwestern.edu (Daniel Kornhauser) Date: Wed, 19 Nov 2008 13:59:29 -0600 Subject: [Rd] Buggy trellis.focus() with xyplot in JavaGD ? Message-ID: <332394640811191159t7f01b146yfce2bd0633dd443@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From murdoch at stats.uwo.ca Wed Nov 19 21:52:38 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Wed, 19 Nov 2008 15:52:38 -0500 Subject: [Rd] Strategy for downloading packages Message-ID: <49247C96.3010504@stats.uwo.ca> I have a client who wants to install R and a custom package on a machine with no internet connection, so he wants to put everything needed on a CDROM and install from there. I've told him how to work out what is needed, but it seems that too much manual work is needed: he needs to install the packages from .zip files (this is Windows) in the right order so dependencies are met, etc. Is there an automated tool to do this? That is: - start from an R installation that's working, and then follow the dependency tree from a specified list of packages to generate a list of packages to download - download all the .zip or .tar.gz files for those from CRAN (possibly listing the ones that don't exist there, because they are local custom ones) - produce a script that can be run to install all of them on a new R install. Duncan Murdoch From simon.urbanek at r-project.org Wed Nov 19 22:07:54 2008 From: simon.urbanek at r-project.org (Simon Urbanek) Date: Wed, 19 Nov 2008 16:07:54 -0500 Subject: [Rd] Strategy for downloading packages In-Reply-To: <49247C96.3010504@stats.uwo.ca> References: <49247C96.3010504@stats.uwo.ca> Message-ID: <168D1CBD-2D85-49EB-B1E9-B35A7EE61740@r-project.org> On Nov 19, 2008, at 15:52 , Duncan Murdoch wrote: > I have a client who wants to install R and a custom package on a > machine with no internet connection, so he wants to put everything > needed on a CDROM and install from there. > > I've told him how to work out what is needed, but it seems that too > much manual work is needed: he needs to install the packages > from .zip files (this is Windows) in the right order so dependencies > are met, etc. > Why would that be necessary? The order is plays no role, since all it's just unpacking, so you can as well burn the content of the installed library and you're set... Or am I missing something? Cheers, S > Is there an automated tool to do this? That is: > > - start from an R installation that's working, and then follow the > dependency tree from a specified list of packages to generate a list > of packages to download > - download all the .zip or .tar.gz files for those from CRAN > (possibly listing the ones that don't exist there, because they are > local custom ones) > - produce a script that can be run to install all of them on a new R > install. > > Duncan Murdoch > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > From ripley at stats.ox.ac.uk Wed Nov 19 22:16:56 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 21:16:56 +0000 (GMT) Subject: [Rd] Strategy for downloading packages In-Reply-To: <49247C96.3010504@stats.uwo.ca> References: <49247C96.3010504@stats.uwo.ca> Message-ID: On Wed, 19 Nov 2008, Duncan Murdoch wrote: > I have a client who wants to install R and a custom package on a machine with > no internet connection, so he wants to put everything needed on a CDROM and > install from there. > > I've told him how to work out what is needed, but it seems that too much > manual work is needed: he needs to install the packages from .zip files > (this is Windows) in the right order so dependencies are met, etc. I don't think the install order matters for binary packages (on Windows or elsewhere). install.packages() certainly does not optimize it. > Is there an automated tool to do this? That is: The easiest way is to copy a repository to the CD-ROM, and point repos at that (as a file::// URL). You can even add files and rebuild the PACKAGES file (using tools::write_PACKAGES). But if the list of packages never changes, why not just install them in a separate library and burn that on the CD-ROM? > - start from an R installation that's working, and then follow the > dependency tree from a specified list of packages to generate a list of > packages to download > - download all the .zip or .tar.gz files for those from CRAN (possibly > listing the ones that don't exist there, because they are local custom ones) > - produce a script that can be run to install all of them on a new R > install. > > Duncan Murdoch > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From murdoch at stats.uwo.ca Wed Nov 19 22:30:36 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Wed, 19 Nov 2008 16:30:36 -0500 Subject: [Rd] Strategy for downloading packages In-Reply-To: <168D1CBD-2D85-49EB-B1E9-B35A7EE61740@r-project.org> References: <49247C96.3010504@stats.uwo.ca> <168D1CBD-2D85-49EB-B1E9-B35A7EE61740@r-project.org> Message-ID: <4924857C.2090208@stats.uwo.ca> On 11/19/2008 4:07 PM, Simon Urbanek wrote: > On Nov 19, 2008, at 15:52 , Duncan Murdoch wrote: > >> I have a client who wants to install R and a custom package on a >> machine with no internet connection, so he wants to put everything >> needed on a CDROM and install from there. >> >> I've told him how to work out what is needed, but it seems that too >> much manual work is needed: he needs to install the packages >> from .zip files (this is Windows) in the right order so dependencies >> are met, etc. >> > > Why would that be necessary? The order is plays no role, since all > it's just unpacking, so you can as well burn the content of the > installed library and you're set... Or am I missing something? Thanks, I didn't realize that the install order doesn't matter. But in the longer term, he'll probably want to do this himself, so he'll still need to generate the list of dependencies and download them. Or maybe just burning a copy of the installed library is what he should do --- I'd just be worried about versioning issues if he tries to update the install without starting from scratch. Duncan Murdoch > > Cheers, > S > > > >> Is there an automated tool to do this? That is: >> >> - start from an R installation that's working, and then follow the >> dependency tree from a specified list of packages to generate a list >> of packages to download >> - download all the .zip or .tar.gz files for those from CRAN >> (possibly listing the ones that don't exist there, because they are >> local custom ones) >> - produce a script that can be run to install all of them on a new R >> install. >> >> Duncan Murdoch >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From murdoch at stats.uwo.ca Wed Nov 19 22:33:46 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Wed, 19 Nov 2008 16:33:46 -0500 Subject: [Rd] Strategy for downloading packages In-Reply-To: References: <49247C96.3010504@stats.uwo.ca> Message-ID: <4924863A.4010308@stats.uwo.ca> On 11/19/2008 4:16 PM, Prof Brian Ripley wrote: > On Wed, 19 Nov 2008, Duncan Murdoch wrote: > >> I have a client who wants to install R and a custom package on a machine with >> no internet connection, so he wants to put everything needed on a CDROM and >> install from there. >> >> I've told him how to work out what is needed, but it seems that too much >> manual work is needed: he needs to install the packages from .zip files >> (this is Windows) in the right order so dependencies are met, etc. > > I don't think the install order matters for binary packages (on Windows or > elsewhere). install.packages() certainly does not optimize it. Thanks, as I mentioned to Simon I didn't know this. That definitely makes things simpler. > >> Is there an automated tool to do this? That is: > > The easiest way is to copy a repository to the CD-ROM, and point repos at > that (as a file::// URL). You can even add files and rebuild the PACKAGES > file (using tools::write_PACKAGES). > > But if the list of packages never changes, why not just install them in a > separate library and burn that on the CD-ROM? In the long run, the first order dependencies won't likely change, but their dependencies might. We didn't write those packages, we just use them. Duncan Murdoch > >> - start from an R installation that's working, and then follow the >> dependency tree from a specified list of packages to generate a list of >> packages to download >> - download all the .zip or .tar.gz files for those from CRAN (possibly >> listing the ones that don't exist there, because they are local custom ones) >> - produce a script that can be run to install all of them on a new R >> install. >> >> Duncan Murdoch >> >> ______________________________________________ >> R-devel at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > From p.murrell at auckland.ac.nz Wed Nov 19 22:54:59 2008 From: p.murrell at auckland.ac.nz (Paul Murrell) Date: Thu, 20 Nov 2008 10:54:59 +1300 Subject: [Rd] grid error: protection stack overflow In-Reply-To: <94730b8a0811132327g1ee7691ajdc5c41d61dd14bb4@mail.gmail.com> References: <94730b8a0811132327g1ee7691ajdc5c41d61dd14bb4@mail.gmail.com> Message-ID: <49248B33.9090100@stat.auckland.ac.nz> Hi Felix Andrews wrote: > I have isolated an error that can be reproduced by the following code. > The same thing happens in 2.8.0pat and 2.9.0dev. It looks like the > try() code is ending up in the display list, or something? The problem was that the *unsuccessful* downViewport() was ending up on the display list (which lead to an infinite loop on a display list replay, which produced the error). I have committed a fix to r-devel. Thanks for the report! Paul p.s. A side-bug that this investigation exposed is that using try() on graphics code can have the effect (when an error occurs) of turning off display list recording for the device. No solution in sight for that bug, so best to stay away from try() for now, as your follow up email suggested. > library(grid) > library(lattice) > > xyplot(1:100 ~ 1:100) > test <- try(downViewport("pageAnnotationVp"), silent = TRUE) > downViewport(trellis.vpname("toplevel")) > pushViewport(viewport(name = "pageAnnotationVp", yscale = c(1, 0))) > upViewport(0) > > ## resize device to trigger a couple of redraws... > > Error: protect(): protection stack overflow > > Enter a frame number, or 0 to exit > 1: no.children() > 2: ls(children, all.names = TRUE) > 3: try(name) > 4: tryCatch(expr, error = function(e) { > 5: tryCatchList(expr, classes, parentenv, handlers) > 6: tryCatchOne(expr, names, parentenv, handlers[[1]]) > 7: doTryCatch(return(expr), name, parentenv, handler) > > >> sessionInfo() > R version 2.8.0 Patched (2008-11-10 r46884) > i386-pc-mingw32 > > locale: > LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=English_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252 > > attached base packages: > [1] grid stats graphics grDevices utils datasets > methods base > > other attached packages: > [1] lattice_0.17-15 > > -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 paul at stat.auckland.ac.nz http://www.stat.auckland.ac.nz/~paul/ From gilescrane at verizon.net Wed Nov 19 15:05:04 2008 From: gilescrane at verizon.net (gilescrane at verizon.net) Date: Wed, 19 Nov 2008 15:05:04 +0100 (CET) Subject: [Rd] paste() retains quotes (PR#13304) Message-ID: <20081119140504.E94D6282EFC1@mail.pubhealth.ku.dk> Full_Name: Giles L Crane Version: 2.8.0 2008-10-20 OS: Windows XP Submission from: (NULL) (71.168.215.186) paste(rep(" ",10),sep="") [1] " " " " " " " " " " " " " " " " " " " " As I read the documentation for paste(), this should have produced " " that is, all spaces pasted together. Hope this is helpful. GLC From zemlys at gmail.com Wed Nov 19 15:44:11 2008 From: zemlys at gmail.com (Vaidotas Zemlys) Date: Wed, 19 Nov 2008 16:44:11 +0200 Subject: [Rd] (PR#13234) Problems with Sweave and pdf.options(encoding="ISOLatin7") In-Reply-To: References: <20081031093507.EF812282C76E@mail.pubhealth.ku.dk> Message-ID: 2008/11/19 Prof Brian Ripley : > On Wed, 19 Nov 2008, Vaidotas Zemlys wrote: > >> OK, the modified R code is: >> >> >> plot(rnorm(100),main="\u0105\u010D\u0117\u0119\u012F\u0161\u016B\u0173\u017E") >> >> It does not work correctly with Sweave, as I wrote in my email, I >> rechecked. And yes it works if only pdf is used. > > It works for me in xpdf, but not Acroread 8.1.3. Yes, I checked only with evince, and assumed, that Acroread will be similar. Acrobat 9 (on windows) shows the letters, but they are bunched up together. Changing the default family to URWHelvetica did not help either. So that rules out using pdf for me. > >> >> I did not find any mention about encodings in ?Sweave, ?RweaveLatex >> and ?Rtangle, and Sweave manual and FAQ. > > Yes, Sweave is supposedly frozen pending unbundling. > > Note that this does work (at least for me) in lt_LT.utf8: it is because you > were in fr_FR.utf8 that you had a problem. > > So I think the solution is actually pretty simple: use the correct locale. > I've changed R-patched to take the defaults from pdf.options(), but Sweave > should still be able to set them. > Aah, this does not occured to me. I thought that because locale is unicode it should not matter which unicode letters I use. That is a not correct assumption. Thank you for your answers, Vaidotas Zemlys From whorfin at pixar.com Wed Nov 19 19:50:09 2008 From: whorfin at pixar.com (whorfin at pixar.com) Date: Wed, 19 Nov 2008 19:50:09 +0100 (CET) Subject: [Rd] qr.coef and complex numbers - still busted for non-square case? (PR#13305) Message-ID: <20081119185009.B38B7282EFC1@mail.pubhealth.ku.dk> Full_Name: Rick Sayre Version: 2.8.0 OS: windows, linux, os x Submission from: (NULL) (138.72.153.166) PR#8476 and PR#8478 http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8478 http://bugs.r-project.org/cgi-bin/R/Models-fixed?id=8476 discuss fixing qr.coef to handle complex matrices correctly But it appears the solution now "shipping" only handles square matrices. In 2.8.0 [linux, windows, and os x] non-square complex arguments cause an error. > qr.solve(cbind(1:11,1),2*(20:30)) [1] 2 38 > qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30))) Error in coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base") : number of items to replace is not a multiple of replacement length If I change the section shown by context below from qr.coef as follows: if (is.complex(qr$qr)) { if (!is.complex(y)) y[] <- as.complex(y) coef <- matrix(NA_complex_, nrow = p, ncol = ny) #coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base") coef[qr$pivot, ] <- .Call("qr_coef_cmplx", qr, y, PACKAGE = "base")[1:p,] return(if (im) coef else c(coef)) } then i get goodness: my.qr.solve(cbind(as.complex(1:11),as.complex(1)),as.complex(2*(20:30))) [1] 2+0i 38+0i I do not pretend to fully understand the afflicted code, so it is very likely "I'm doing it wrong". What I just did above is exactly what Chris proposed in #8478, but it appears this was declared to be incorrect and changed. The current code in qr.coef seems to handle square complex matrices, but as you see above, it does not handle non-square conditions. From ripley at stats.ox.ac.uk Wed Nov 19 23:13:14 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Wed, 19 Nov 2008 22:13:14 +0000 (GMT) Subject: [Rd] paste() retains quotes (PR#13304) In-Reply-To: <20081119140504.E94D6282EFC1@mail.pubhealth.ku.dk> References: <20081119140504.E94D6282EFC1@mail.pubhealth.ku.dk> Message-ID: On Wed, 19 Nov 2008, gilescrane at verizon.net wrote: > Full_Name: Giles L Crane > Version: 2.8.0 2008-10-20 > OS: Windows XP > Submission from: (NULL) (71.168.215.186) > > > paste(rep(" ",10),sep="") > [1] " " " " " " " " " " " " " " " " " " " " > > As I read the documentation for paste(), > this should have produced > " " > that is, all spaces pasted together. You read it wrong: that is what collapse="" does. > Hope this is helpful. Quite the reverse, a beginners' mistake. > GLC > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From deepayan.sarkar at gmail.com Thu Nov 20 02:33:18 2008 From: deepayan.sarkar at gmail.com (Deepayan Sarkar) Date: Wed, 19 Nov 2008 17:33:18 -0800 Subject: [Rd] Buggy trellis.focus() with xyplot ? In-Reply-To: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> Message-ID: On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser wrote: > Hi: > > (Tried to find a bug report about this issue, but was unable to find it, let > me know if this is a known issue) > I have been working on an interface to highlight xyplot panels on mouse > overs in JavaGD but I have stumbled with what seems to be a bug in > trellis.focus. > I am using R 2.8 with lattice 0.17-15 > > > *** To replicate the bug: > 1.- display an xyplot. For example, from the xyplot help page: > library(lattice) > require(stats) > EE <- equal.count(ethanol$E, number=9, overlap=1/4) > ## Constructing panel functions on the fly; prepanel > xyplot(NOx ~ C | EE, data = ethanol, > prepanel = function(x, y) prepanel.loess(x, y, span = 1), > xlab = "Compression Ratio", ylab = "NOx (micrograms/J)", > panel = function(x, y) { > panel.grid(h=-1, v= 2) > panel.xyplot(x, y) > panel.loess(x,y, span=1) > }, > aspect = "xy") > 2.- resize to window be rectangular and have large margins in the left hand > and right hand side. > 3.- run trellis.focus() and try to select the first or last panel, you > should observe that it does not select the right one. > > sidenotes: > There are other problems with the focus in JavaGD but I just wanted to > include a simple self contained example in this mail. > If you make the window smaller, trellis.focus() works fine, you have to make > it bigger than the initial size. > > > *** To Fix the bug: > I tried to fix this bug in interraction.R but I was unsuccesful. > > The problem should stem from the a bad calculation of the pads in the > follwoing lines : > leftPad <- > convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc", > valueOnly = TRUE) > rightPad <- > convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), "npc", > valueOnly = TRUE) > topPad <- > convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc", > valueOnly = TRUE) > botPad <- > convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), "npc", > valueOnly = TRUE) > > I was succesful in tweaking the follwing lines adding arbitrary constants to > make it work for a particular instance of a xyplot with a particular size of > a window > clickXScaled <- (as.numeric(clickLoc$x) - leftPad + Danielconstant1) > / (1 - leftPad - rightPad + Danielconstant1) > .... > clickYScaled <- (as.numeric(clickLoc$y) - botPad + Danielconstant2) > / (1 - botPad - topPad + Danielconstant3) > This is of course a useless fix, since you want the fix to work for any plot > with any window size, but I might be valuable information. > > > *** Questions: > - Is this a real bug ? > - Any suggestions for fixing it ? > - If it can't be fixed, is there a way around this bug ? > (For example, setting the margins to be zero and set a fixed size for the > xplot) It appears that the conversions used in the current implementation (contributed by Felix Andrews) don't work when aspect != "fill" (probably leading back to the use of 'respect = TRUE' in grid.layout). The right way to do this is to first go down to the subregion containing just the panels, and then locate the click location within it. But this requires a suitable viewport to be predefined. I have changed print.trellis to create such a dummy viewport (accessible by trellis.focus("figure")), and modified trellis.focus() to use it. I will test it a bit more before uploading a new version (and also give Felix a chance to see if this breaks anything in playwith etc.). To see if the fix works, you can try the svn copy at https://svn.r-project.org/R-packages/trunk/lattice -Deepayan From felix at nfrac.org Thu Nov 20 03:10:30 2008 From: felix at nfrac.org (Felix Andrews) Date: Thu, 20 Nov 2008 13:10:30 +1100 Subject: [Rd] Buggy trellis.focus() with xyplot ? In-Reply-To: References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> Message-ID: <94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com> 2008/11/20 Deepayan Sarkar : > On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser > wrote: >> Hi: >> >> (Tried to find a bug report about this issue, but was unable to find it, let >> me know if this is a known issue) >> I have been working on an interface to highlight xyplot panels on mouse >> overs in JavaGD but I have stumbled with what seems to be a bug in >> trellis.focus. >> I am using R 2.8 with lattice 0.17-15 >> >> >> *** To replicate the bug: >> 1.- display an xyplot. For example, from the xyplot help page: >> library(lattice) >> require(stats) >> EE <- equal.count(ethanol$E, number=9, overlap=1/4) >> ## Constructing panel functions on the fly; prepanel >> xyplot(NOx ~ C | EE, data = ethanol, >> prepanel = function(x, y) prepanel.loess(x, y, span = 1), >> xlab = "Compression Ratio", ylab = "NOx (micrograms/J)", >> panel = function(x, y) { >> panel.grid(h=-1, v= 2) >> panel.xyplot(x, y) >> panel.loess(x,y, span=1) >> }, >> aspect = "xy") >> 2.- resize to window be rectangular and have large margins in the left hand >> and right hand side. >> 3.- run trellis.focus() and try to select the first or last panel, you >> should observe that it does not select the right one. >> >> sidenotes: >> There are other problems with the focus in JavaGD but I just wanted to >> include a simple self contained example in this mail. >> If you make the window smaller, trellis.focus() works fine, you have to make >> it bigger than the initial size. >> >> >> *** To Fix the bug: >> I tried to fix this bug in interraction.R but I was unsuccesful. >> >> The problem should stem from the a bad calculation of the pads in the >> follwoing lines : >> leftPad <- >> convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc", >> valueOnly = TRUE) >> rightPad <- >> convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), "npc", >> valueOnly = TRUE) >> topPad <- >> convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc", >> valueOnly = TRUE) >> botPad <- >> convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), "npc", >> valueOnly = TRUE) >> >> I was succesful in tweaking the follwing lines adding arbitrary constants to >> make it work for a particular instance of a xyplot with a particular size of >> a window >> clickXScaled <- (as.numeric(clickLoc$x) - leftPad + Danielconstant1) >> / (1 - leftPad - rightPad + Danielconstant1) >> .... >> clickYScaled <- (as.numeric(clickLoc$y) - botPad + Danielconstant2) >> / (1 - botPad - topPad + Danielconstant3) >> This is of course a useless fix, since you want the fix to work for any plot >> with any window size, but I might be valuable information. >> >> >> *** Questions: >> - Is this a real bug ? >> - Any suggestions for fixing it ? >> - If it can't be fixed, is there a way around this bug ? >> (For example, setting the margins to be zero and set a fixed size for the >> xplot) > > It appears that the conversions used in the current implementation > (contributed by Felix Andrews) don't work when aspect != "fill" > (probably leading back to the use of 'respect = TRUE' in grid.layout). Yep, my fault, didn't think it through. > The right way to do this is to first go down to the subregion > containing just the panels, and then locate the click location within > it. But this requires a suitable viewport to be predefined. > > I have changed print.trellis to create such a dummy viewport > (accessible by trellis.focus("figure")), and modified trellis.focus() > to use it. I will test it a bit more before uploading a new version > (and also give Felix a chance to see if this breaks anything in It won't affect playwith; playwith now uses a different approach: a function inViewport(x.px, y.px, viewport) reports whether a click location in pixels is inside the given viewport. I loop through each panel viewport and check whether the click is inside. > playwith etc.). To see if the fix works, you can try the svn copy at > > https://svn.r-project.org/R-packages/trunk/lattice > > -Deepayan > -- Felix Andrews / ??? http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 From dkor at northwestern.edu Thu Nov 20 03:35:41 2008 From: dkor at northwestern.edu (Daniel Kornhauser) Date: Wed, 19 Nov 2008 20:35:41 -0600 Subject: [Rd] Buggy trellis.focus() with xyplot ? In-Reply-To: <94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com> References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> <94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com> Message-ID: <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From felix at nfrac.org Thu Nov 20 05:26:24 2008 From: felix at nfrac.org (Felix Andrews) Date: Thu, 20 Nov 2008 15:26:24 +1100 Subject: [Rd] Buggy trellis.focus() with xyplot ? In-Reply-To: <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com> References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> <94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com> <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com> Message-ID: <94730b8a0811192026j119657aay6dfb8d699d01ddea@mail.gmail.com> 2008/11/20 Daniel Kornhauser : > Thanks a lot for taking this on guys ! > > Some more background in case you are interested: > > I have almost a working version of focus for selecting a panel with mouse > over in a stanalone Java application using an REngine I only have two > issues: > > - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes > 1.5 seconds to unfocus, do you know any way to speed it up ? Yep, redrawing R plots is slow. If you remove a grob the whole plot needs to be redrawn. The solution is to use highlight = FALSE in the trellis.focus() command. Obviously then there will be no visual indication (red outline) of which panel is in focus. (If you need that you could draw it yourself and then overpaint it with white to hide it, maybe... the best solution would be to draw it using Java graphics, rather than R graphics, and store a buffer, but I don't know whether that's possible in your system). > > - the conversion problem that Deepayan referred too in the previous, but I > guess that will be fixed soon. :-) > > > I am working in a bastardized version of trellis.focus taking an x and y > from an event handler (in Java, C, etc ...) which focuses and highlights the > panel so the REngine instance can perform more operations on the selected > panel. > This would be very useful for easily creating GUI for interactive > visualizations exploration of large multidimensional data sets using lattice > and geared towards non programmers. > > I don't really know what I am getting into, so any advice would be welcomed. Sounds similar to some of the functionality of the 'playwith' and/or 'latticist' packages. You might want to look at them. playwith is built with GTK+. > > Daniel. > > > 2008/11/19 Felix Andrews >> >> 2008/11/20 Deepayan Sarkar : >> > On Wed, Nov 19, 2008 at 8:55 AM, Daniel Kornhauser >> > wrote: >> >> Hi: >> >> >> >> (Tried to find a bug report about this issue, but was unable to find >> >> it, let >> >> me know if this is a known issue) >> >> I have been working on an interface to highlight xyplot panels on mouse >> >> overs in JavaGD but I have stumbled with what seems to be a bug in >> >> trellis.focus. >> >> I am using R 2.8 with lattice 0.17-15 >> >> >> >> >> >> *** To replicate the bug: >> >> 1.- display an xyplot. For example, from the xyplot help page: >> >> library(lattice) >> >> require(stats) >> >> EE <- equal.count(ethanol$E, number=9, overlap=1/4) >> >> ## Constructing panel functions on the fly; prepanel >> >> xyplot(NOx ~ C | EE, data = ethanol, >> >> prepanel = function(x, y) prepanel.loess(x, y, span = 1), >> >> xlab = "Compression Ratio", ylab = "NOx (micrograms/J)", >> >> panel = function(x, y) { >> >> panel.grid(h=-1, v= 2) >> >> panel.xyplot(x, y) >> >> panel.loess(x,y, span=1) >> >> }, >> >> aspect = "xy") >> >> 2.- resize to window be rectangular and have large margins in the left >> >> hand >> >> and right hand side. >> >> 3.- run trellis.focus() and try to select the first or last panel, you >> >> should observe that it does not select the right one. >> >> >> >> sidenotes: >> >> There are other problems with the focus in JavaGD but I just wanted to >> >> include a simple self contained example in this mail. >> >> If you make the window smaller, trellis.focus() works fine, you have to >> >> make >> >> it bigger than the initial size. >> >> >> >> >> >> *** To Fix the bug: >> >> I tried to fix this bug in interraction.R but I was unsuccesful. >> >> >> >> The problem should stem from the a bad calculation of the pads in the >> >> follwoing lines : >> >> leftPad <- >> >> convertX(sum(glayout$page.layout$widths[1:(colRange[1]-1)]), "npc", >> >> valueOnly = TRUE) >> >> rightPad <- >> >> convertX(sum(glayout$page.layout$widths[(colRange[2]+1):layCols]), >> >> "npc", >> >> valueOnly = TRUE) >> >> topPad <- >> >> convertY(sum(glayout$page.layout$heights[1:(rowRange[1]-1)]), "npc", >> >> valueOnly = TRUE) >> >> botPad <- >> >> convertY(sum(glayout$page.layout$heights[(rowRange[2]+1):layRows]), >> >> "npc", >> >> valueOnly = TRUE) >> >> >> >> I was succesful in tweaking the follwing lines adding arbitrary >> >> constants to >> >> make it work for a particular instance of a xyplot with a particular >> >> size of >> >> a window >> >> clickXScaled <- (as.numeric(clickLoc$x) - leftPad + >> >> Danielconstant1) >> >> / (1 - leftPad - rightPad + Danielconstant1) >> >> .... >> >> clickYScaled <- (as.numeric(clickLoc$y) - botPad + >> >> Danielconstant2) >> >> / (1 - botPad - topPad + Danielconstant3) >> >> This is of course a useless fix, since you want the fix to work for any >> >> plot >> >> with any window size, but I might be valuable information. >> >> >> >> >> >> *** Questions: >> >> - Is this a real bug ? >> >> - Any suggestions for fixing it ? >> >> - If it can't be fixed, is there a way around this bug ? >> >> (For example, setting the margins to be zero and set a fixed size for >> >> the >> >> xplot) >> > >> > It appears that the conversions used in the current implementation >> > (contributed by Felix Andrews) don't work when aspect != "fill" >> > (probably leading back to the use of 'respect = TRUE' in grid.layout). >> >> Yep, my fault, didn't think it through. >> >> > The right way to do this is to first go down to the subregion >> > containing just the panels, and then locate the click location within >> > it. But this requires a suitable viewport to be predefined. >> > >> > I have changed print.trellis to create such a dummy viewport >> > (accessible by trellis.focus("figure")), and modified trellis.focus() >> > to use it. I will test it a bit more before uploading a new version >> > (and also give Felix a chance to see if this breaks anything in >> >> It won't affect playwith; playwith now uses a different approach: a >> function >> inViewport(x.px, y.px, viewport) >> reports whether a click location in pixels is inside the given >> viewport. I loop through each panel viewport and check whether the >> click is inside. >> >> > playwith etc.). To see if the fix works, you can try the svn copy at >> > >> > https://svn.r-project.org/R-packages/trunk/lattice >> > >> > -Deepayan >> > >> >> >> -- >> Felix Andrews / ??? >> http://www.neurofractal.org/felix/ >> 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 > > -- Felix Andrews / ??? http://www.neurofractal.org/felix/ 3358 543D AAC6 22C2 D336 80D9 360B 72DD 3E4C F5D8 From deepayan.sarkar at gmail.com Thu Nov 20 06:30:07 2008 From: deepayan.sarkar at gmail.com (Deepayan Sarkar) Date: Wed, 19 Nov 2008 21:30:07 -0800 Subject: [Rd] Buggy trellis.focus() with xyplot ? In-Reply-To: <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com> References: <332394640811190855x61d7e18bice50937205d27c68@mail.gmail.com> <94730b8a0811191810p1c1f5108x61fa899db1f9c8ef@mail.gmail.com> <332394640811191835s2570f901pe179ceacbec7bbef@mail.gmail.com> Message-ID: On 11/19/08, Daniel Kornhauser wrote: > Thanks a lot for taking this on guys ! > > Some more background in case you are interested: > > I have almost a working version of focus for selecting a panel with mouse > over in a stanalone Java application using an REngine I only have two > issues: > > - trellis.unfocus() is terribly slow in a plot of 10 x 10 panels, it takes > 1.5 seconds to unfocus, do you know any way to speed it up ? Call as trellis.unfocus(highlight=FALSE). Unhighlighting essentially redraws the whole thing (this would be true whenever any component is removed, though adding is fine). -Deepayan From braunm at MIT.EDU Thu Nov 20 21:25:16 2008 From: braunm at MIT.EDU (Michael Braun) Date: Thu, 20 Nov 2008 15:25:16 -0500 Subject: [Rd] Turning off compiler optimization Message-ID: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> Hi. I am writing some code in C that I would like to link into R. My Makevars file is: PKG_CPPFLAGS=-I/usr/local/include PKG_LIBS=-L/usr/local/lib -lgsl PKG_CFLAGS = -Wall -O0 -g -p -pg The source file is core.c,. and I am compiling using R CMD SHLIB core.c The output is gcc -arch x86_64 -O3 -g -p -std=gnu99 -I/Library/Frameworks/ R.framework/Resources/include -I/Library/Frameworks/R.framework/ Resources/include/x86_64 -I/usr/local/include -I/usr/local/include - Wall -O0 -g -p -pg -fPIC -g -O2 -c core.c -o core.o gcc -arch x86_64 -O3 -g -p -std=gnu99 -dynamiclib -Wl,- headerpad_max_install_names -undefined dynamic_lookup -single_module - multiply_defined suppress -L/usr/local/lib -o core.so core.o -L/usr/ local/lib -lgsl -F/Library/Frameworks/R.framework/.. -framework R - Wl,-framework -Wl,CoreFoundation I am running R 2.7.1 on a Mac Pro (Intel-based) with OS X 10.5.5. My problem is that, for debugging purposes, I would like to turn off compiler optimization (so gdb stops telling me that values are temporarily unavailable due to optimizations). I thought I was doing that by putting the -O0 flag in PKG_CFLAGS in the Makevars file. But from the output, it looks like there is still some optimization going on. I would also like to avoid writing a Make file from scratch, if at all possible. I looked through the documentation and archives, and was unable to find a solution to this. Can someone offer some assistance? Thanks, Michael ------------------------------------------- Michael Braun Homer A. Burnell Career Development Professor, and Assistant Professor of Management Science (Marketing Group) MIT Sloan School of Management One Amherst St., E40-169 Cambridge, MA 02142 braunm at mit.edu 617-253-3436 From khansen at stat.berkeley.edu Thu Nov 20 22:02:34 2008 From: khansen at stat.berkeley.edu (Kasper Daniel Hansen) Date: Fri, 21 Nov 2008 08:02:34 +1100 Subject: [Rd] Turning off compiler optimization In-Reply-To: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> References: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> Message-ID: <17C77B25-DF5F-4F18-B422-B56C09365E33@stat.berkeley.edu> This is what I am using, suggested a long time ago by Simon Urbanek. I would really like a good way way to override optimization flags - in my package I have code that does not work with -O2. I use the following lines in my Makevars MYCXXFLAGS=-O0 %.o: %.cpp $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< -o $@ Kasper On Nov 21, 2008, at 7:25 , Michael Braun wrote: > Hi. I am writing some code in C that I would like to link into R. > > My Makevars file is: > > PKG_CPPFLAGS=-I/usr/local/include > PKG_LIBS=-L/usr/local/lib -lgsl > PKG_CFLAGS = -Wall -O0 -g -p -pg > > The source file is core.c,. and I am compiling using R CMD SHLIB > core.c The output is > > gcc -arch x86_64 -O3 -g -p -std=gnu99 -I/Library/Frameworks/ > R.framework/Resources/include -I/Library/Frameworks/R.framework/ > Resources/include/x86_64 -I/usr/local/include -I/usr/local/include > -Wall -O0 -g -p -pg -fPIC -g -O2 -c core.c -o core.o > > gcc -arch x86_64 -O3 -g -p -std=gnu99 -dynamiclib -Wl,- > headerpad_max_install_names -undefined dynamic_lookup - > single_module -multiply_defined suppress -L/usr/local/lib -o core.so > core.o -L/usr/local/lib -lgsl -F/Library/Frameworks/R.framework/.. - > framework R -Wl,-framework -Wl,CoreFoundation > > I am running R 2.7.1 on a Mac Pro (Intel-based) with OS X 10.5.5. > > My problem is that, for debugging purposes, I would like to turn off > compiler optimization (so gdb stops telling me that values are > temporarily unavailable due to optimizations). I thought I was > doing that by putting the -O0 flag in PKG_CFLAGS in the Makevars > file. But from the output, it looks like there is still some > optimization going on. I would also like to avoid writing a Make > file from scratch, if at all possible. > > I looked through the documentation and archives, and was unable to > find a solution to this. Can someone offer some assistance? > > Thanks, > > Michael > > > > ------------------------------------------- > Michael Braun > Homer A. Burnell Career Development Professor, and > Assistant Professor of Management Science (Marketing Group) > MIT Sloan School of Management > One Amherst St., E40-169 > Cambridge, MA 02142 > braunm at mit.edu > 617-253-3436 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From edd at debian.org Thu Nov 20 22:09:41 2008 From: edd at debian.org (Dirk Eddelbuettel) Date: Thu, 20 Nov 2008 15:09:41 -0600 Subject: [Rd] Turning off compiler optimization In-Reply-To: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> References: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> Message-ID: <18725.53781.563136.338239@ron.nulle.part> On 20 November 2008 at 15:25, Michael Braun wrote: | Hi. I am writing some code in C that I would like to link into R. | | My Makevars file is: | | PKG_CPPFLAGS=-I/usr/local/include | PKG_LIBS=-L/usr/local/lib -lgsl | PKG_CFLAGS = -Wall -O0 -g -p -pg | | The source file is core.c,. and I am compiling using R CMD SHLIB | core.c The output is | | gcc -arch x86_64 -O3 -g -p -std=gnu99 -I/Library/Frameworks/ | R.framework/Resources/include -I/Library/Frameworks/R.framework/ | Resources/include/x86_64 -I/usr/local/include -I/usr/local/include - | Wall -O0 -g -p -pg -fPIC -g -O2 -c core.c -o core.o | | gcc -arch x86_64 -O3 -g -p -std=gnu99 -dynamiclib -Wl,- | headerpad_max_install_names -undefined dynamic_lookup -single_module - | multiply_defined suppress -L/usr/local/lib -o core.so core.o -L/usr/ | local/lib -lgsl -F/Library/Frameworks/R.framework/.. -framework R - | Wl,-framework -Wl,CoreFoundation | | I am running R 2.7.1 on a Mac Pro (Intel-based) with OS X 10.5.5. | | My problem is that, for debugging purposes, I would like to turn off | compiler optimization (so gdb stops telling me that values are | temporarily unavailable due to optimizations). I thought I was doing | that by putting the -O0 flag in PKG_CFLAGS in the Makevars file. But | from the output, it looks like there is still some optimization going | on. I would also like to avoid writing a Make file from scratch, if | at all possible. | | I looked through the documentation and archives, and was unable to | find a solution to this. Can someone offer some assistance? One way is to edit $RHOME/etc/Makeconf by hand and remove the settings left there from the build-time configuration. Another way is to not use R CMD SHLIB but to craft a simple Makefile, copying the same commands that R CMD SHLIB shows you, and editing what you want to change. I often to that for development. Hth, Dirk -- Three out of two people have difficulties with fractions. From ripley at stats.ox.ac.uk Thu Nov 20 22:34:50 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Thu, 20 Nov 2008 21:34:50 +0000 (GMT) Subject: [Rd] Turning off compiler optimization In-Reply-To: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> References: <8EB66ACA-70E3-4F4C-9F1E-695C44882179@mit.edu> Message-ID: Use .R/Makeconf: see 'R Installation and Administration' section 6.3.3. On Thu, 20 Nov 2008, Michael Braun wrote: > Hi. I am writing some code in C that I would like to link into R. > > My Makevars file is: > > PKG_CPPFLAGS=-I/usr/local/include > PKG_LIBS=-L/usr/local/lib -lgsl > PKG_CFLAGS = -Wall -O0 -g -p -pg > > The source file is core.c,. and I am compiling using R CMD SHLIB core.c The > output is > > gcc -arch x86_64 -O3 -g -p -std=gnu99 > -I/Library/Frameworks/R.framework/Resources/include > -I/Library/Frameworks/R.framework/Resources/include/x86_64 > -I/usr/local/include -I/usr/local/include -Wall -O0 -g -p -pg -fPIC -g -O2 > -c core.c -o core.o > > gcc -arch x86_64 -O3 -g -p -std=gnu99 -dynamiclib > -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module > -multiply_defined suppress -L/usr/local/lib -o core.so core.o > -L/usr/local/lib -lgsl -F/Library/Frameworks/R.framework/.. -framework R > -Wl,-framework -Wl,CoreFoundation > > I am running R 2.7.1 on a Mac Pro (Intel-based) with OS X 10.5.5. > > My problem is that, for debugging purposes, I would like to turn off compiler > optimization (so gdb stops telling me that values are temporarily unavailable > due to optimizations). I thought I was doing that by putting the -O0 flag in > PKG_CFLAGS in the Makevars file. But from the output, it looks like there is > still some optimization going on. I would also like to avoid writing a Make > file from scratch, if at all possible. > > I looked through the documentation and archives, and was unable to find a > solution to this. Can someone offer some assistance? > > Thanks, > > Michael > > > > ------------------------------------------- > Michael Braun > Homer A. Burnell Career Development Professor, and > Assistant Professor of Management Science (Marketing Group) > MIT Sloan School of Management > One Amherst St., E40-169 > Cambridge, MA 02142 > braunm at mit.edu > 617-253-3436 > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From josef.leydold at wu-wien.ac.at Thu Nov 20 19:15:18 2008 From: josef.leydold at wu-wien.ac.at (josef.leydold at wu-wien.ac.at) Date: Thu, 20 Nov 2008 19:15:18 +0100 (CET) Subject: [Rd] dchisq hangs in infinite loop (PR#13309) Message-ID: <20081120181518.D3760282C765@mail.pubhealth.ku.dk> Full_Name: Josef Leyold Version: 2.9.0 (2008-11-20 r46997) OS: Linux Submission from: (NULL) (137.208.56.12) Hi, the command dchisq(x=Inf,df=10,ncp=1) causes R to hang in an (almost?) infinite loop. It also happens for x=1.e50. Josef p.s. the problem also occurs in version 2.7.2 > R.version _ platform x86_64-unknown-linux-gnu arch x86_64 os linux-gnu system x86_64, linux-gnu status Under development (unstable) major 2 minor 9.0 year 2008 month 11 day 20 svn rev 46997 language R version.string R version 2.9.0 Under development (unstable) (2008-11-20 r46997) From martin.bader at unibas.ch Thu Nov 20 14:45:11 2008 From: martin.bader at unibas.ch (martin.bader at unibas.ch) Date: Thu, 20 Nov 2008 14:45:11 +0100 (CET) Subject: [Rd] Label justification (axis) (PR#13307) Message-ID: <20081120134511.A6EC0283417B@mail.pubhealth.ku.dk> Full_Name: Martin Karl-Friedrich Bader Version: 2.8.0 OS: 10.5.3 Submission from: (NULL) (131.152.1.1) Hi there, when using las=1 on the y-axis the labels keep their centered justification, e.g. if you plot a graph using the axis command: axis(side=2, at=c(0,50, 100, 125), lab=c("0","50","100", " "), las=1), then the 0 and the 50 are centered in relation to the 100! One can work around that problem by inserting blank spaces in front of the lower numbers (e.g.: " 0") but that's not an appropriate solution! Is there a way that can be fixed? Thanks in advance! Martin From ripley at stats.ox.ac.uk Fri Nov 21 11:09:02 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Fri, 21 Nov 2008 10:09:02 +0000 (GMT) Subject: [Rd] Label justification (axis) (PR#13307) In-Reply-To: <20081120134511.A6EC0283417B@mail.pubhealth.ku.dk> References: <20081120134511.A6EC0283417B@mail.pubhealth.ku.dk> Message-ID: Can you please provide a complete reproducible example, including the device used. E.g. quartz() # or X11() plot(1:200, yaxt="n", type="n") axis(side=2, at=c(0,50,100,125), lab=c("0","50","100"," "), las=1) does not work as you describe (R 2.8.0 in R.app, Mac OS 10.5.5). On Thu, 20 Nov 2008, martin.bader at unibas.ch wrote: > Full_Name: Martin Karl-Friedrich Bader > Version: 2.8.0 > OS: 10.5.3 Is that Solaris or SuSE or HP-UX or Mac OS? As only Windows and Mac users seem to be in denial about there being any other OS, I suspect we can infer .... > Submission from: (NULL) (131.152.1.1) > > > Hi there, > > when using las=1 on the y-axis the labels keep their centered justification, > e.g. if you plot a graph using the axis command: axis(side=2, at=c(0,50, 100, > 125), lab=c("0","50","100", " "), las=1), then the 0 and the 50 are centered in > relation to the 100! One can work around that problem by inserting blank spaces > in front of the lower numbers (e.g.: " 0") but that's not an appropriate > solution! Is there a way that can be fixed? Thanks in advance! > > Martin > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From kjell.konis at epfl.ch Fri Nov 21 11:11:29 2008 From: kjell.konis at epfl.ch (Kjell Konis) Date: Fri, 21 Nov 2008 11:11:29 +0100 Subject: [Rd] Label justification (axis) (PR#13307) In-Reply-To: <20081120134511.A6EC0283417B@mail.pubhealth.ku.dk> References: <20081120134511.A6EC0283417B@mail.pubhealth.ku.dk> Message-ID: If you want to change the orientation of the axis labels you use las. If you want to change the horizontal justification of the axis labels you use hadj. If you want to change the orientation of the axis labels and the horizontal justification of the axis labels then you use las and hadj at the same time. On 20 nov. 08, at 14:45, martin.bader at unibas.ch wrote: > Full_Name: Martin Karl-Friedrich Bader > Version: 2.8.0 > OS: 10.5.3 > Submission from: (NULL) (131.152.1.1) > > > Hi there, > > when using las=1 on the y-axis the labels keep their centered > justification, > e.g. if you plot a graph using the axis command: axis(side=2, > at=c(0,50, 100, > 125), lab=c("0","50","100", " "), las=1), then the 0 and the 50 are > centered in > relation to the 100! One can work around that problem by inserting > blank spaces > in front of the lower numbers (e.g.: " 0") but that's not an > appropriate > solution! Is there a way that can be fixed? Thanks in advance! > > Martin > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From maechler at stat.math.ethz.ch Fri Nov 21 11:20:07 2008 From: maechler at stat.math.ethz.ch (maechler at stat.math.ethz.ch) Date: Fri, 21 Nov 2008 11:20:07 +0100 (CET) Subject: [Rd] dchisq hangs in infinite loop (PR#13309) Message-ID: <20081121102007.A60052834158@mail.pubhealth.ku.dk> >>>>> "jl" == josef leydold >>>>> on Thu, 20 Nov 2008 19:15:18 +0100 (CET) writes: jl> Full_Name: Josef Leyold jl> Version: 2.9.0 (2008-11-20 r46997) jl> OS: Linux jl> Submission from: (NULL) (137.208.56.12) jl> Hi, jl> the command jl> dchisq(x=Inf,df=10,ncp=1) jl> causes R to hang in an (almost?) infinite loop. jl> It also happens for x=1.e50. Indeed. I will fix this shortly, for R 2.8.0 patched and R-devel. Thanks a lot, Josef, for the report! Martin jl> Josef jl> p.s. the problem also occurs in version 2.7.2 >> R.version jl> _ jl> platform x86_64-unknown-linux-gnu jl> arch x86_64 jl> os linux-gnu jl> system x86_64, linux-gnu jl> status Under development (unstable) jl> major 2 jl> minor 9.0 jl> year 2008 jl> month 11 jl> day 20 jl> svn rev 46997 jl> language R jl> version.string R version 2.9.0 Under development (unstable) (2008-11-20 r46997) From yan at pixie.org.uk Fri Nov 21 14:20:03 2008 From: yan at pixie.org.uk (yan at pixie.org.uk) Date: Fri, 21 Nov 2008 14:20:03 +0100 (CET) Subject: [Rd] edge label position in plot.dendrogram(..., horiz=T) (PR#13313) Message-ID: <20081121132003.93442282C761@mail.pubhealth.ku.dk> Full_Name: Yan Wong Version: 2.8.0 OS: Mac OS X 10.4 Submission from: (NULL) (78.149.183.231) Using R 2.8.0 under Mac OS X, I find that edge labels do not change position to account for the "horiz" argument of plot.dendrogram, for example > d <- as.dendrogram(hclust(dist(list(a=1,b=2,c=4,d=5)))) > attr(d[[1]], "edgetext") <- "a & b" > attr(d[[2]], "edgetext") <- "c & d" > plot(d, horiz="F") #OK > plot(d, horiz="T") #edge labels do not change position to account for horiz I think this is because stats:::plotNode doesn't deal with horiz=TRUE on line 152 (starting "polygon(mx + c(-hl3, hl3),"). From yan at pixie.org.uk Fri Nov 21 14:50:05 2008 From: yan at pixie.org.uk (yan at pixie.org.uk) Date: Fri, 21 Nov 2008 14:50:05 +0100 (CET) Subject: [Rd] cex.lab etc. ignored in plot.ts for multiple plots (PR#13315) Message-ID: <20081121135005.0CE7D283416C@mail.pubhealth.ku.dk> Full_Name: Yan Wong Version: 2.8.0 OS: Mac OS X 10.4 Submission from: (NULL) (78.149.183.231) When plotting multiple time series in a single plot, via plot.ts(plot.type="multiple"), the cex.lab, col.lab, and font.lab arguments are ignored > plot(ts(data.frame(a=1:10, b=1:10)), plot.type="single", cex.lab=0.5, col.lab="red") #tiny red axis labels > plot(ts(data.frame(a=1:10, b=1:10)), plot.type="multiple", cex.lab=0.5, col.lab="red") #should have tiny red axis labels, but does not. I think this a problem with lines 54-57 of plot.ts. In particular, the mtext functions should also be called with 'cex=cex.lab, col=col.lab, font=font.lab', and the argument list of the plotts function should also contain 'cex.lab=par("cex.lab"), col.lab=par("col.lab"), font.lab=par("font.lab")' From fabian.scheipl at stat.uni-muenchen.de Fri Nov 21 17:00:03 2008 From: fabian.scheipl at stat.uni-muenchen.de (fabian.scheipl at stat.uni-muenchen.de) Date: Fri, 21 Nov 2008 17:00:03 +0100 (CET) Subject: [Rd] Wishlist: fix error in documentation for body<- (PR#13318) Message-ID: <20081121160003.8DFAC2834154@mail.pubhealth.ku.dk> Full_Name: Fabian Scheipl Version: 2.8.0 OS: Windows, Linux Submission from: (NULL) (138.246.7.150) It seems to me that the documentation for body<- is wrong. The help file for body(fun, envir = environment(fun)) <- value says that: value can be an expression or a list of R expressions. This produces errors however: ################################ > f <- function(x){} > body(f) <- list(expression(res <- x^2),expression(return(x))) Fehler in as.function.default(c(formals(fun), value), envir) : ung?ltiges formales Argument f?r "function" ################################ The only way to assign multiple statements to a function body that I could get to work is to put all the statements into a single expression, (separated by ';' and in curly brackets): ################################ body(f) <- expression({res <- x^2; return(x)}) ################################ I think the words 'or a list of R expressions.' should be removed. From p.dalgaard at biostat.ku.dk Fri Nov 21 23:46:17 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Fri, 21 Nov 2008 23:46:17 +0100 Subject: [Rd] Wishlist: fix error in documentation for body<- (PR#13318) In-Reply-To: <20081121160003.8DFAC2834154@mail.pubhealth.ku.dk> References: <20081121160003.8DFAC2834154@mail.pubhealth.ku.dk> Message-ID: <49273A39.6020908@biostat.ku.dk> fabian.scheipl at stat.uni-muenchen.de wrote: > Full_Name: Fabian Scheipl > Version: 2.8.0 > OS: Windows, Linux > Submission from: (NULL) (138.246.7.150) > > > It seems to me that the documentation for body<- is wrong. > The help file for > > body(fun, envir = environment(fun)) <- value > > says that: > > value can be an expression or a list of R expressions. > > This produces errors however: > > ################################ > >> f <- function(x){} >> body(f) <- list(expression(res <- x^2),expression(return(x))) > Fehler in as.function.default(c(formals(fun), value), envir) : > ung?ltiges formales Argument f?r "function" > > ################################ > > > The only way to assign multiple statements to a function body > that I could get to work is to put all the statements into a single expression, > (separated by ';' and in curly brackets): > > ################################ > > body(f) <- expression({res <- x^2; return(x)}) > > ################################ > > I think the words 'or a list of R expressions.' should be removed. It's slightly trickier than that. The value _can_ be a list, but only one of length 1. The same actually goes for expressions, but in that case there is explicit code to take only the first element. Also, the distinction between objects of mode "expression" and unevaluated expressions is unclear (here and elsewhere). > body(f) <- expression(x,y,z) > f function () x > body(f) <- list(quote(2+2)) > f function () 2 + 2 > body(f) <- list(expression(2+2)) > f function () expression(2 + 2) BTW: Don't use 'wishlist' on things that are real errors. -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From mflawren at fhcrc.org Sat Nov 22 04:45:15 2008 From: mflawren at fhcrc.org (Michael Lawrence) Date: Fri, 21 Nov 2008 19:45:15 -0800 Subject: [Rd] wish: exportClassPattern Message-ID: <509e0620811211945i5d26ad64lad026de4928fabdb@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From ripley at stats.ox.ac.uk Sat Nov 22 07:26:35 2008 From: ripley at stats.ox.ac.uk (Prof Brian Ripley) Date: Sat, 22 Nov 2008 06:26:35 +0000 (GMT) Subject: [Rd] wish: exportClassPattern In-Reply-To: <509e0620811211945i5d26ad64lad026de4928fabdb@mail.gmail.com> References: <509e0620811211945i5d26ad64lad026de4928fabdb@mail.gmail.com> Message-ID: Michael, This seems a reasonable request, but most of us will not have enough classes in a package for it to make a difference. A patch to do this would certainly speed up implementation. On Fri, 21 Nov 2008, Michael Lawrence wrote: > It would be nice to have a more convenient means of exporting multiple > classes from a package namespace. Why not have something like > exportClassPattern() that worked like exportPattern() except for classes? > > Thanks, > Michael > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Brian D. Ripley, ripley at stats.ox.ac.uk 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, UK Fax: +44 1865 272595 From ggrothendieck at gmail.com Sat Nov 22 09:33:45 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sat, 22 Nov 2008 03:33:45 -0500 Subject: [Rd] cex.lab etc. ignored in plot.ts for multiple plots (PR#13315) In-Reply-To: <20081121135005.0CE7D283416C@mail.pubhealth.ku.dk> References: <20081121135005.0CE7D283416C@mail.pubhealth.ku.dk> Message-ID: <971536df0811220033x389438b7l7e2ef415eae8fff7@mail.gmail.com> As a workaround you could use plot.zoo: library(zoo) tt <- ts(cbind(a = 1:10, b = 1:10)) plot(as.zoo(tt), plot.type="multiple", cex.lab = 0.5, col.lab = "red") On Fri, Nov 21, 2008 at 8:50 AM, wrote: > Full_Name: Yan Wong > Version: 2.8.0 > OS: Mac OS X 10.4 > Submission from: (NULL) (78.149.183.231) > > > When plotting multiple time series in a single plot, via > plot.ts(plot.type="multiple"), the cex.lab, col.lab, and font.lab arguments are > ignored > >> plot(ts(data.frame(a=1:10, b=1:10)), plot.type="single", cex.lab=0.5, > col.lab="red") #tiny red axis labels >> plot(ts(data.frame(a=1:10, b=1:10)), plot.type="multiple", cex.lab=0.5, > col.lab="red") #should have tiny red axis labels, but does not. > > I think this a problem with lines 54-57 of plot.ts. In particular, the mtext > functions should also be called with 'cex=cex.lab, col=col.lab, font=font.lab', > and the argument list of the plotts function should also contain > 'cex.lab=par("cex.lab"), col.lab=par("col.lab"), font.lab=par("font.lab")' > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From ali.baharev at gmail.com Sat Nov 22 19:18:35 2008 From: ali.baharev at gmail.com (Ali Baharev) Date: Sat, 22 Nov 2008 19:18:35 +0100 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <49204FF8.9040706@wald.ucdavis.edu> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> <49204FF8.9040706@wald.ucdavis.edu> Message-ID: <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> Dear Developers, For the attached (very simple) source package i get the following warnings: * checking foreign function calls ... WARNING Foreign function calls without 'PACKAGE' argument: .C("fpow", ...) See the chapter 'System and foreign language interfaces' of the 'Writing R Extensions' manual. * checking R code for possible problems ... NOTE Error in firstlib(which.lib.loc, package) : Tcl/Tk support is not available on this system After looking at the manual, i could not figure out how to fix them. Please also point out other possible problems not found by R CMD check. Many thanks, Ali -------------- next part -------------- A non-text attachment was scrubbed... Name: fpow_0.0-1.tar.gz Type: application/x-gzip Size: 3226 bytes Desc: not available URL: From duncan at wald.ucdavis.edu Sat Nov 22 23:21:16 2008 From: duncan at wald.ucdavis.edu (Duncan Temple Lang) Date: Sat, 22 Nov 2008 14:21:16 -0800 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> <49204FF8.9040706@wald.ucdavis.edu> <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> Message-ID: <492885DC.4010307@wald.ucdavis.edu> Ali Baharev wrote: > Dear Developers, > > For the attached (very simple) source package i get the following warnings: > > * checking foreign function calls ... WARNING > Foreign function calls without 'PACKAGE' argument: > .C("fpow", ...) > See the chapter 'System and foreign language interfaces' of the 'Writing R > Extensions' manual. > The message is reasonably clear. Calls to .C(), .Call(), .Fortran(), .External() must identify the DLL/shared object so that the native (compiled) symbol being invoked is correctly found and we don't end up by chance finding another with the same name in another DLL/shared object. So you need .C("fpow", PACKAGE = "fpow") If you had a NAMESPACE for the package, you can chose to omit the PACKAGE = "fpow" if you want as we infer that the DLL is the one associated with this package. > * checking R code for possible problems ... NOTE > Error in firstlib(which.lib.loc, package) : > Tcl/Tk support is not available on this system This is just a note and of no concern. > > After looking at the manual, i could not figure out how to fix them. > > Please also point out other possible problems not found by R CMD check. > > Many thanks, > > Ali From ali.baharev at gmail.com Sat Nov 22 23:26:50 2008 From: ali.baharev at gmail.com (Ali Baharev) Date: Sat, 22 Nov 2008 23:26:50 +0100 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <492885DC.4010307@wald.ucdavis.edu> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> <49204FF8.9040706@wald.ucdavis.edu> <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> <492885DC.4010307@wald.ucdavis.edu> Message-ID: <34dd040c0811221426u5573f34n12a012feaa9fea6f@mail.gmail.com> Many thanks! Otherwise did you find the source OK? Please note that i have not used R. I just did what i could understand from the manuals. Thanks, Ali From ali.baharev at gmail.com Sat Nov 22 23:35:22 2008 From: ali.baharev at gmail.com (Ali Baharev) Date: Sat, 22 Nov 2008 23:35:22 +0100 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <34dd040c0811221426u5573f34n12a012feaa9fea6f@mail.gmail.com> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> <49204FF8.9040706@wald.ucdavis.edu> <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> <492885DC.4010307@wald.ucdavis.edu> <34dd040c0811221426u5573f34n12a012feaa9fea6f@mail.gmail.com> Message-ID: <34dd040c0811221435r665b4967ud291bc1f5d409e4c@mail.gmail.com> Ooops, sorry. Just one more question. Do i have to make a binary package for Win32 and Mac OS X? Or is it done by some server side scripts? For Win32 it seems to me http://win-builder.r-project.org/ can build it for me. Sorry for the dumb questions. Ali From ggrothendieck at gmail.com Sat Nov 22 23:41:40 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sat, 22 Nov 2008 17:41:40 -0500 Subject: [Rd] Computing minimal detectable differences for general ANOVA models In-Reply-To: <34dd040c0811221435r665b4967ud291bc1f5d409e4c@mail.gmail.com> References: <34dd040c0811160806g4513ea6ci318a2f43c2ddbefa@mail.gmail.com> <49204FF8.9040706@wald.ucdavis.edu> <34dd040c0811221018w743cfd51p559f9e3b4a223931@mail.gmail.com> <492885DC.4010307@wald.ucdavis.edu> <34dd040c0811221426u5573f34n12a012feaa9fea6f@mail.gmail.com> <34dd040c0811221435r665b4967ud291bc1f5d409e4c@mail.gmail.com> Message-ID: <971536df0811221441j362e2340x8ff625e45f8c4086@mail.gmail.com> They will be built for you. You only upload the .tar.gz file. See section 1.5 of the Writing Extensions manual. On Sat, Nov 22, 2008 at 5:35 PM, Ali Baharev wrote: > Ooops, sorry. Just one more question. > > Do i have to make a binary package for Win32 and Mac OS X? Or is it > done by some server side scripts? > > For Win32 it seems to me > > http://win-builder.r-project.org/ > > can build it for me. > > Sorry for the dumb questions. > > Ali > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From pburns at pburns.seanet.com Sun Nov 23 17:27:37 2008 From: pburns at pburns.seanet.com (Patrick Burns) Date: Sun, 23 Nov 2008 16:27:37 +0000 Subject: [Rd] minor typo in assignOps help file Message-ID: <49298479.3000005@pburns.seanet.com> There is a minor typo in the help file for assignOps: There is no space in "operator<-" in the second sentence of the second paragraph of the Details section. Patrick Burns patrick at burns-stat.com +44 (0)20 8525 0696 http://www.burns-stat.com (home of S Poetry and "A Guide for the Unwilling S User") From murdoch at stats.uwo.ca Sun Nov 23 19:22:53 2008 From: murdoch at stats.uwo.ca (Duncan Murdoch) Date: Sun, 23 Nov 2008 13:22:53 -0500 Subject: [Rd] minor typo in assignOps help file In-Reply-To: <49298479.3000005@pburns.seanet.com> References: <49298479.3000005@pburns.seanet.com> Message-ID: <49299F7D.90804@stats.uwo.ca> On 23/11/2008 11:27 AM, Patrick Burns wrote: > There is a minor typo in the help file for assignOps: > > There is no space in "operator<-" in the second > sentence of the second paragraph of the Details > section. Thanks, I'll fix that. Duncan Murdoch From Thomas.Mang at fiwi.at Mon Nov 24 10:02:20 2008 From: Thomas.Mang at fiwi.at (Thomas Mang) Date: Mon, 24 Nov 2008 10:02:20 +0100 Subject: [Rd] timezone attribute lost Message-ID: Hi, As I didn't get any response on the general help list and I don't know if there is a bug in action I am trying my luck here. I was highly surprised to find out that during simple operations (see code below) the timezone attribute for POSIXct data is lost and then, upon the next interpretation, the system settings are used (which are plain wrong in my case). I have used R 2.8.0 under Windows XP with the system timezone (managed by Windows) set to CET - I suppose however that all other timezones, with the exception of GMT, will show similiar surprising behavior (and those who live in GMT-zone: If you change your timezone setting please restart R, otherwise the effect won't take place). # input data # note that the timezone is deliberately set to GMT, and of course I want the operations below to take place in GMT-time Time = as.POSIXct(strptime(c("2007-12-12 14:30:15", "2008-04-14 15:31:34", "2008-04-14 15:31:34"), format = "%Y-%m-%d %H:%M:%S", tz = "GMT")) Time # OK, time zone is GMT attr(Time, "tzone") # OK, time zone is GMT # Surprise 1: TApply = tapply(1:3, Time, max) names(TApply) # wrong, names are converted to time zone of system # Surprise 2: UTime = unique(Time) UTime # wrong, again time zone of system is used attr(UTime, "tzone") # == NULL I know how to "solve" the problem (for example by setting an R system variable TZ to GMT), but I wonder why is this mess happening at all? Moreover, is this behavior considered to be a feature, or a plain bug ? Thanks, Thomas From hkawakat at gmail.com Mon Nov 24 16:01:48 2008 From: hkawakat at gmail.com (Hiroyuki Kawakatsu) Date: Mon, 24 Nov 2008 15:01:48 +0000 Subject: [Rd] make fails with no rule to make target `VR.ts' Message-ID: <307b90470811240701q3e7c6244u7e58ef7de8d72969@mail.gmail.com> Hi, When trying to build R-devel.tar.bz2 (SVN-REVISION: 47015) I am getting the error: tkpager text html latex gmake[2]: Leaving directory `/usr/local/share/R-devel/src/library' gmake[2]: Entering directory `/usr/local/share/R-devel/src/library' building/updating package indices ... gmake[2]: Leaving directory `/usr/local/share/R-devel/src/library' gmake[1]: Leaving directory `/usr/local/share/R-devel/src/library' gmake[1]: Entering directory `/usr/local/share/R-devel/src/library/Recommended' gmake[2]: Entering directory `/usr/local/share/R-devel/src/library/Recommended' gmake[2]: *** No rule to make target `VR.ts', needed by `stamp-recommended'. Stop. gmake[2]: Leaving directory `/usr/local/share/R-devel/src/library/Recommended' gmake[1]: *** [recommended-packages] Error 2 gmake[1]: Leaving directory `/usr/local/share/R-devel/src/library/Recommended' gmake: *** [stamp-recommended] Error 2 This is on FreeBSD 7.0-RELEASE (amd64) with ./configure MAKE=gmake CC=gcc44 F77=gfortran44 FC=gfortran44 CXX=g++44 OBJC=gcc44 R_BROWSER=/usr/local/bin/firefox3 This used to build fine until a few weeks ago. Any hints for what may be going wrong? h. -- +--- | Hiroyuki Kawakatsu | Business School, Dublin City University | Dublin 9, Ireland. Tel +353 (0)1 700 7496 From pgilbert at bank-banque-canada.ca Mon Nov 24 17:48:03 2008 From: pgilbert at bank-banque-canada.ca (Paul Gilbert) Date: Mon, 24 Nov 2008 11:48:03 -0500 Subject: [Rd] CRAN - db backend testing In-Reply-To: <49253B79.5000907@statistik.tu-dortmund.de> References: <491CA2B0.6000204@vanderbilt.edu> <18720.17441.551053.30889@ron.nulle.part> <4921906E.5000103@bank-banque-canada.ca> <49219544.20402@bank-banque-canada.ca> <4921A81D.9070300@bank-banque-canada.ca> <4922875B.9060601@statistik.tu-dortmund.de> <49234355.4030303@bank-banque-canada.ca> <49253B79.5000907@statistik.tu-dortmund.de> Message-ID: <492ADAC3.1040506@bank-banque-canada.ca> (thread renamed from Re: [R-sig-DB] RMySQL release candidate 0-7.0) Building on Uwe's comments and my own thoughts I suggest variables like SKIP_POSTGRESQL, SKIP_MYSQL, SKIP_SQLITE, SKIP_ORACLE, SKIP_ODBC, SKIP_FAME be used to signal that tests should not be run. If these are not set to something then the tests will be attempted, so skipping the tests is not likely to happen by accident. This would also clearly separate the mechanism for deciding if the tests should be run from the mechanism for determining details like the userid. The tests files would then have something like if ((Sys.getenv("SKIP_POSTGRESSQL") == "")) { tests } Then, if variables like POSTGRES_USER, POSTGRES_HOST, POSTGRES_DATABASE (more on DATABASE below) are found they will be used, otherwise nothing is specified and the drivers will typically read values from configuration files like .my.cnf and .pgpass. It would be nice to have a mechanism for examples, vignettes, and demos, but I don't see any nice way to do this. Paul Gilbert wrote: >> However, there is still a problem of potential conflicts on database >> "test" if parallel testing occurs. (I've had this problem already.) It >> would be better if "test" were replaced by a pid specific db, but this >> requires the userid to have database create rights. > Uwe Ligges wrote: > At least I will try to avoid checking of more than one RMySQL instance .... This does not solve the problem, since one server instance can respond to multiple clients. So, if odbc and RPostgreSQL both talk to the same PostgreSQL server and use the database "test" they can collide (fairly easily if packages are testing similar functionality with different drivers). This problem is even more severe when testing on multiple clients with a single server, which is a problem for my own testing but may not be for CRAN. Paul ==================================================================================== La version fran?aise suit le texte anglais. ------------------------------------------------------------------------------------ This email may contain privileged and/or confidential in...{{dropped:26}} From wdunlap at tibco.com Mon Nov 24 18:36:18 2008 From: wdunlap at tibco.com (William Dunlap) Date: Mon, 24 Nov 2008 09:36:18 -0800 Subject: [Rd] timezone attribute lost In-Reply-To: References: Message-ID: <77EB52C6DD32BA4D87471DCD70C8D7003CF430@NA-PA-VBE03.na.tibco.com> > From: r-devel-bounces at r-project.org > [mailto:r-devel-bounces at r-project.org] On Behalf Of Thomas Mang > Sent: Monday, November 24, 2008 1:02 AM > To: r-devel at stat.math.ethz.ch > Subject: [Rd] timezone attribute lost > > Hi, > > As I didn't get any response on the general help list and I > don't know > if there is a bug in action I am trying my luck here. > > I was highly surprised to find out that during simple operations (see > code below) the timezone attribute for POSIXct data is lost and then, > upon the next interpretation, the system settings are used (which are > plain wrong in my case). > > I have used R 2.8.0 under Windows XP with the system timezone > (managed > by Windows) set to CET - I suppose however that all other timezones, > with the exception of GMT, will show similiar surprising > behavior (and > those who live in GMT-zone: If you change your timezone > setting please > restart R, otherwise the effect won't take place). > > > # input data > # note that the timezone is deliberately set to GMT, and of course I > want the operations below to take place in GMT-time > Time = as.POSIXct(strptime(c("2007-12-12 14:30:15", "2008-04-14 > 15:31:34", "2008-04-14 15:31:34"), format = "%Y-%m-%d %H:%M:%S", tz = > "GMT")) > Time # OK, time zone is GMT > attr(Time, "tzone") # OK, time zone is GMT > > > # Surprise 1: > TApply = tapply(1:3, Time, max) > names(TApply) # wrong, names are converted to time zone of system > > # Surprise 2: > UTime = unique(Time) > UTime # wrong, again time zone of system is used > attr(UTime, "tzone") # == NULL > > > I know how to "solve" the problem (for example by setting an R system > variable TZ to GMT), but I wonder why is this mess happening at all? > Moreover, is this behavior considered to be a feature, or a > plain bug ? All of those problems are due to a problem in unique.default(), which sends the integer data in POSIXct, Date, and factor objects through a .Internal and then tries to reconstruct the original sort of object from the integer output of that .Internal() z <- .Internal(unique(x, incomparables, fromLast)) if (is.factor(x)) factor(z, levels = seq_len(nlevels(x)), labels = levels(x), ordered = is.ordered(x)) else if (inherits(x, "POSIXct") || inherits(x, "Date")) structure(z, class = class(x)) Your immediately problem could be solved by adding tzone=attr(x,"tzone") to the structure call, but I'm not familiar enough with classes inheriting from POSIXct and Date to know if that is sufficient. There is no reason someone won't make a new subclass where another attribute is essential. Since .Internal used the equivalent of as.numeric(x) to extract numeric codes, it might be nice to have an as.numeric<-(x,value) function that could insert numeric codes back into a dataset so you could avoid reconstructing an object of unknown structure with as.numeric(x)<-z (or perhaps as.vector<- should be used so you don't have to know what the integer type is). In S and S+ one can use x at .Data<-newNumericCodes for this sort of thing, but that can be dangerous because it lets you stick in inappropriate types. One might think that adding a new unique method for POSIXct or Date or things subclassed from them would be the right way to structure things, but factor() explicitly calls unique.default(). > Thanks, > Thomas > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Bill Dunlap TIBCO Software Inc - Spotfire Division wdunlap tibco.com From bxc at steno.dk Mon Nov 24 15:39:21 2008 From: bxc at steno.dk (BXC (Bendix Carstensen)) Date: Mon, 24 Nov 2008 15:39:21 +0100 Subject: [Rd] FW: read.ssd Message-ID: <2F73FA3AF524144C863B7C2C903DBC3301F9319673@exdkmbx002.corp.novocorp.net> Did not seem to reach Saikat DebRoy, this might be the forum. Bendix -----Original Message----- From: BXC (Bendix Carstensen) Sent: 24. november 2008 15:00 To: 'saikat at stat.wisc.edu'; 'stvjc at channing.harvard.edu' Subject: read.ssd It's always annoyed me that that read.ssd crashed on datasets with long variable names, but the other day a collegue of mine pointed out to me the SAS-option validvarname=V6, which takes care of the problem by truncating names. So here is a first go at it which works, but lets you guess what variable the truncated names refer to (normally a minor problem). The small changes in the code are flagged with "####". Hope it makes it into read.ssd. If you want to supply information on the long filename or even restore them, the solution is to construct a proc contents step and output the filenames along with their labels, import this dataset too and use it to restore names. This is considerably more longwinded and could presumably wait. The little example SAS-program should give the details of the SAS-code needed, but a lot of namefidgeting in R is required afterward to make it work... Best regards, Bendix ______________________________________________ Bendix Carstensen Senior Statistician Steno Diabetes Center Niels Steensens Vej 2-4 DK-2820 Gentofte Denmark +45 44 43 87 38 (direct) +45 30 75 87 38 (mobile) bxc at steno.dk http://www.biostat.ku.dk/~bxc This e-mail (including any attachments) is intended for the addressee(s) stated above only and may contain confidential information protected by law. You are hereby notified that any unauthorized reading, disclosure, copying or distribution of this e-mail or use of information contained herein is strictly prohibited and may violate rights to proprietary information. If you are not an intended recipient, please return this e-mail to the sender and delete it immediately hereafter. Thank you. From bolker at ufl.edu Mon Nov 24 22:55:17 2008 From: bolker at ufl.edu (Ben Bolker) Date: Mon, 24 Nov 2008 16:55:17 -0500 Subject: [Rd] [R] besselK In-Reply-To: <6A102055-34F6-4F69-A976-0DB8541342F2@exeter.ac.uk> References: <6A102055-34F6-4F69-A976-0DB8541342F2@exeter.ac.uk> Message-ID: <492B22C5.4090104@ufl.edu> [cc'ing to R-devel] It's moderately obscure to me too, but ... There are two sets of bessel code in the package, one in C++ from Chris Bond and the other in FORTRAN from Netlib (I think). The FORTRAN code is the one that's giving trouble, you might try just removing the FORTRAN code from the src directory and trying again. http://www.tek-tips.com/viewthread.cfm?qid=1296207&page=11 Eventually it would be nice to get both sets of code running on multiple platforms, for comparison's sake -- the code that's failing (machcon.f) is the code to define machine-dependent constants -- this is a fairly standard set of routines from NETLIB, but they're very grungy in that you're just supposed to uncomment the constants that are relevant to your system. There must be a better way to do this with configure/looking in system libraries etc. (I don't really know how this is done in FORTRAN). Does anyone out there have experience in porting code from Netlib and ending up with clean, platform-configured code? (I will go look at the deSolve package next, but since this is a bit of a side project ...) Ben Bolker baptiste auguie wrote: > Dear Ben, > > Many thanks for the effort you put into this. Out of curiosity I located > an earlier package (sparma) on your webpage yesterday, but ran into some > problem when installing it, related to 'machcon.f ' . A similar problem > comes up when I try to install complexbessel. It must be a fairly > trivial glitch, but the compilation fails on both machines I've tried > with the following error log: > >> gfortran -fno-range-check -c machcon.f -o machcon.o >> machcon.f: In function ?r1mach?: >> machcon.f:696: fatal error: gfc_todo: Not Implemented: Initialization >> of overlapping variables >> compilation terminated. > > The cause of this error is quite obscure to me, perhaps you've seen this > message before? > > Many thanks again, > > baptiste > > > On MacOS10.5, R2.8, > >> baptiste:Desktop baptiste$ R CMD INSTALL complexbessel_0.0.1.tar.gz >> * Installing to library >> '/Library/Frameworks/R.framework/Resources/library' >> * Installing *source* package 'complexbessel' ... >> ** libs >> ** arch - i386 >> gfortran -arch i386 -fPIC -g -O2 -c Rzbesk.f -o Rzbesk.o >> g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include >> -I/Library/Frameworks/R.framework/Resources/include/i386 >> -I/usr/local/include -fPIC -g -O2 -c cbessik-wrap.cc -o >> cbessik-wrap.o >> g++ -arch i386 -I/Library/Frameworks/R.framework/Resources/include >> -I/Library/Frameworks/R.framework/Resources/include/i386 >> -I/usr/local/include -fPIC -g -O2 -c cbessik.cc -o cbessik.o >> gfortran -fno-range-check -c machcon.f -o machcon.o >> machcon.f: In function ?r1mach?: >> machcon.f:696: fatal error: gfc_todo: Not Implemented: Initialization >> of overlapping variables >> compilation terminated. >> make: *** [machcon.o] Error 1 >> chmod: >> /Library/Frameworks/R.framework/Resources/library/complexbessel/libs/i386/*: >> No such file or directory >> ** arch - ppc >> gfortran -arch ppc -fPIC -g -O2 -c Rzbesk.f -o Rzbesk.o >> g++ -arch ppc -I/Library/Frameworks/R.framework/Resources/include >> -I/Library/Frameworks/R.framework/Resources/include/ppc >> -I/usr/local/include -fPIC -g -O2 -c cbessik-wrap.cc -o >> cbessik-wrap.o >> g++ -arch ppc -I/Library/Frameworks/R.framework/Resources/include >> -I/Library/Frameworks/R.framework/Resources/include/ppc >> -I/usr/local/include -fPIC -g -O2 -c cbessik.cc -o cbessik.o >> gfortran -fno-range-check -c machcon.f -o machcon.o >> machcon.f: In function ?r1mach?: >> machcon.f:696: fatal error: gfc_todo: Not Implemented: Initialization >> of overlapping variables >> compilation terminated. >> make: *** [machcon.o] Error 1 >> chmod: >> /Library/Frameworks/R.framework/Resources/library/complexbessel/libs/ppc/*: >> No such file or directory >> ERROR: compilation failed for package 'complexbessel' >> ** Removing >> '/Library/Frameworks/R.framework/Resources/library/complexbessel' > > sessionInfo() > R version 2.8.0 (2008-10-20) > i386-apple-darwin8.11.1 > > locale: > en_GB.UTF-8/en_US.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8 > > attached base packages: > [1] stats graphics grDevices utils methods base > > other attached packages: > [1] constants_1.0 spectra_1.0 reshape_0.8.2 > plyr_0.1.3 scatteringR_1.0 latticeExtra_0.5-4 > lattice_0.17-15 baptMisc_1.0 > [9] RColorBrewer_1.0-2 > > loaded via a namespace (and not attached): > [1] grid_2.8.0 tools_2.8.0 > > > Similarly, on ubuntu Gutsy, R2.7: > >> R CMD INSTALL complexbessel/ >> * Installing to library '/home/baptiste/R/i486-pc-linux-gnu-library/2.7' >> * Installing *source* package 'complexbessel' ... >> ** libs >> g++ -I/usr/share/R/include -fpic -g -O2 -c cbessik.cc -o cbessik.o >> g++ -I/usr/share/R/include -fpic -g -O2 -c cbessik-wrap.cc -o >> cbessik-wrap.o >> gfortran -fno-range-check -c machcon.f -o machcon.o >> machcon.f: In function ?r1mach?: >> machcon.f:696: fatal error: gfc_todo: Not Implemented: Initialization >> of overlapping variables >> compilation terminated. >> make: *** [machcon.o] Error 1 >> ERROR: compilation failed for package 'complexbessel' >> ** Removing >> '/home/baptiste/R/i486-pc-linux-gnu-library/2.7/complexbessel' > > > > ________________________________________ > From: Ben Bolker [bolker at ufl.edu] > Sent: 24 November 2008 15:14 > To: Auguie, Baptiste > Subject: Re: [R] besselK > > I took a little time to build a "complexbessel" package. > It's barely documented ... but see if this helps. > It would be nice to test this for speed and accuracy, > document it further, etc ... > > Ben Bolker > > > > baptiste auguie wrote: >> Hello, >> >> I've posted a few messages on the R mailing list concerning bessel >> functions with a complex argument. It appears I missed your post when >> browsing the archives < >> http://tolstoy.newcastle.edu.au/R/e2/help/07/06/19044.html >. >> >> Do you still have the experimental wrapper code you mentioned at this >> occasion? I am not familiar with Fortran, and my attempts at writing >> such wrapper functions have failed. >> >> Best regards, >> >> baptiste >> >> >> >> _____________________________ >> >> Baptiste Augui? >> >> School of Physics >> University of Exeter >> Stocker Road, >> Exeter, Devon, >> EX4 4QL, UK >> >> Phone: +44 1392 264187 >> >> http://newton.ex.ac.uk/research/emag >> ______________________________ >> > > > -- > Ben Bolker > Associate professor, Biology Dep't, Univ. of Florida > bolker at ufl.edu / www.zoology.ufl.edu/bolker > GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc -- Ben Bolker Associate professor, Biology Dep't, Univ. of Florida bolker at ufl.edu / www.zoology.ufl.edu/bolker GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From dawiacount at gmx.de Mon Nov 24 19:58:55 2008 From: dawiacount at gmx.de (Wilm Schumacher) Date: Mon, 24 Nov 2008 19:58:55 +0100 Subject: [Rd] handling a matrix and .C Message-ID: <20081124185855.152920@gmx.net> Hello R-devel, I want to write extensions for R in C (maybe C++ and Fortran later) and it works fine, but there is one problem, which I cannot solve (in my view). I want to handle a matrix from R in C. For arrays there is "as.double(...)", but nothing for a matrix. I searched a while, but didn't find something. Last I looked at the source code of e1071 and of the core itself and recognized (I hope I understood this), that you (and the "e1071" people) use "as.double()" and give ".C" an array and one have to "parse" the matrix again in the C function. This sounds a little complicate. Isn't there another way? A more adapted way? Greetings Wilm ps: I joined the R-devel list, but didn't get an confirmation mail. I hope this is normal -- From bxc at steno.dk Tue Nov 25 10:53:13 2008 From: bxc at steno.dk (BXC (Bendix Carstensen)) Date: Tue, 25 Nov 2008 10:53:13 +0100 Subject: [Rd] FW: read.ssd In-Reply-To: <492BAD83.6060603@biostat.ku.dk> Message-ID: <2F73FA3AF524144C863B7C2C903DBC3301F9319833@exdkmbx002.corp.novocorp.net> Peter D told me the attachments went astray. The files of interest are now in http://staff.pubhealth.ku.dk/~bxc/R-ex/, as read.ssd7.r and for an excample SAS-program that illustrates the the features, see x-xpt.sas. Bendix > -----Original Message----- > From: Peter Dalgaard [mailto:p.dalgaard at biostat.ku.dk] > Sent: 25. november 2008 08:47 > To: BXC (Bendix Carstensen) > Subject: Re: [Rd] FW: read.ssd > > BXC (Bendix Carstensen) wrote: > > Did not seem to reach Saikat DebRoy, this might be the forum. > > Ingen attachment. Din mailer fumler sikkert med Content-Type, > s? mailing list filteret tror at det er noget bin?rt. > > -p > > > Bendix > > > > -----Original Message----- > > From: BXC (Bendix Carstensen) > > Sent: 24. november 2008 15:00 > > To: 'saikat at stat.wisc.edu'; 'stvjc at channing.harvard.edu' > > Subject: read.ssd > > > > It's always annoyed me that that read.ssd crashed on > datasets with long variable names, but the other day a > collegue of mine pointed out to me the SAS-option > validvarname=V6, which takes care of the problem by truncating names. > > > > So here is a first go at it which works, but lets you guess > what variable the truncated names refer to (normally a minor > problem). The small changes in the code are flagged with > "####". Hope it makes it into read.ssd. > > > > If you want to supply information on the long filename or > even restore them, the solution is to construct a proc > contents step and output the filenames along with their > labels, import this dataset too and use it to restore names. > This is considerably more longwinded and could presumably > wait. The little example SAS-program should give the details > of the SAS-code needed, but a lot of namefidgeting in R is > required afterward to make it work... > > > > Best regards, > > Bendix > > ______________________________________________ > > > > Bendix Carstensen > > Senior Statistician > > Steno Diabetes Center > > Niels Steensens Vej 2-4 > > DK-2820 Gentofte > > Denmark > > +45 44 43 87 38 (direct) > > +45 30 75 87 38 (mobile) > > bxc at steno.dk http://www.biostat.ku.dk/~bxc > > > > This e-mail (including any attachments) is intended for the > addressee(s) stated above only and may contain confidential > information protected by law. You are hereby notified that > any unauthorized reading, disclosure, copying or distribution > of this e-mail or use of information contained herein is > strictly prohibited and may violate rights to proprietary > information. If you are not an intended recipient, please > return this e-mail to the sender and delete it immediately > hereafter. Thank you. > > > > > > > > > ---------------------------------------------------------------------- > > -- > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > -- > O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: > (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: > (+45) 35327907 > From Rory.WINSTON at rbs.com Tue Nov 25 12:27:34 2008 From: Rory.WINSTON at rbs.com (Rory.WINSTON at rbs.com) Date: Tue, 25 Nov 2008 11:27:34 +0000 Subject: [Rd] handling a matrix and .C In-Reply-To: References: Message-ID: > Last I looked at the source code of e1071 and of the core itself and recognized (I hope I understood this), that you (and the "e1071" people) use "as.double()" and give ".C" an array and one have to "parse" the matrix again in the C function. I think this is the simplest way to handle matrices at this level - after all a matrix is really an homogenous array of data with indexing information ? I have an example of handling matrices (using .Call) in an old post: http://www.theresearchkitchen.com/blog/archives/113 Cheesr Rory *********************************************************************************** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the=2...{{dropped:22}} From h.wickham at gmail.com Tue Nov 25 19:41:05 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 25 Nov 2008 12:41:05 -0600 Subject: [Rd] Suggestions for improving R-FAQ Message-ID: Currently, if you were to print out the R frequently asked questions (http://cran.r-project.org/doc/FAQ/R-FAQ.html), it would be 132 pages long. Is it any wonder that so many question could be answered by looking at the FAQ but are not? Here are a few (contentious) suggestions to improve the document. * Remove the complete list of R packages * Include a complete list of frequently asked questions at the top of the document * Move the introduction to the end - none of this information is immediately useful for the person who is using the document * Move section seven, which includes the most frequently asked questions to the start * Make "Why doesn't R think these numbers are equal?" the first FAQ since it is the most commonly asked * Remove infrequently asked questions - e.g. 2.3, 2.4, 7.9, 7.11, 7.12, 7.15, 7.19, 7.23, 7.28 * Move sections 3, 6 and 9 into its their own documents Regards, Hadley -- http://had.co.nz/ From h.wickham at gmail.com Tue Nov 25 19:43:33 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 25 Nov 2008 12:43:33 -0600 Subject: [Rd] Suggestions for improving R-FAQ In-Reply-To: References: Message-ID: On Tue, Nov 25, 2008 at 12:41 PM, hadley wickham wrote: > Currently, if you were to print out the R frequently asked questions > (http://cran.r-project.org/doc/FAQ/R-FAQ.html), it would be 132 pages > long. Is it any wonder that so many question could be answered by > looking at the FAQ but are not? Here are a few (contentious) > suggestions to improve the document. > > ... + Add a new FAQ - does R use multiple cores. Hadley -- http://had.co.nz/ From mxkuhn at gmail.com Tue Nov 25 22:10:12 2008 From: mxkuhn at gmail.com (Max Kuhn) Date: Tue, 25 Nov 2008 16:10:12 -0500 Subject: [Rd] Suggestions for improving R-FAQ In-Reply-To: References: Message-ID: <6731304c0811251310m950a5cfu5a6209025c94c98a@mail.gmail.com> Hadley, These are good suggestions. > * Remove infrequently asked questions - e.g. 2.3, 2.4, 7.9, 7.11, > 7.12, 7.15, 7.19, 7.23, 7.28 I'd like to lobby to keep 7.23 and 7.28. I still get questions about those. Sampling bias might be an issue: we don't get questions (to r-help) for those because those are in the FAQ. Perhaps that is wishful thinking on my part. -- Max From h.wickham at gmail.com Tue Nov 25 23:08:12 2008 From: h.wickham at gmail.com (hadley wickham) Date: Tue, 25 Nov 2008 16:08:12 -0600 Subject: [Rd] Suggestions for improving R-FAQ In-Reply-To: <6731304c0811251310m950a5cfu5a6209025c94c98a@mail.gmail.com> References: <6731304c0811251310m950a5cfu5a6209025c94c98a@mail.gmail.com> Message-ID: On Tue, Nov 25, 2008 at 3:10 PM, Max Kuhn wrote: > Hadley, > > These are good suggestions. > >> * Remove infrequently asked questions - e.g. 2.3, 2.4, 7.9, 7.11, >> 7.12, 7.15, 7.19, 7.23, 7.28 Maybe 7.28 should be titled: How can I make read.table (and read.csv and read.fwf)) faster? But personally, I've never found it made much difference - even with a few hundred thousand rows, it takes longer for me to re-remember the colClasses syntax than load in the data. I'm not sure why I thought 7.23 should go. > Sampling bias might be an issue: we don't get questions (to r-help) > for those because those are in the FAQ. Perhaps that is wishful > thinking on my part. It's a possibility, but it seems unlikely that after paging through 125 pages of material to read 7.23 and 7.28 people would stop before getting to 7.31 -- http://had.co.nz/ From lhansen at blackmesacapital.com Tue Nov 25 23:30:23 2008 From: lhansen at blackmesacapital.com (lhansen at blackmesacapital.com) Date: Tue, 25 Nov 2008 23:30:23 +0100 (CET) Subject: [Rd] Problem with installed.packages (PR#13332) Message-ID: <20081125223023.6E418282EFC2@mail.pubhealth.ku.dk> Full_Name: Lars Hansen Version: 2.8.0 OS: Linux Submission from: (NULL) (70.90.201.133) Hi, Calling installed.packages() on a directory with only one package causes an error if the priority argument is set to "NA": > installed.packages(lib.loc = "/home/lhansen/R/libs", priority = "NA") Error in mat[, "Package"] : incorrect number of dimensions This seems like a classic dropping from matrix to vector bug. Maybe the code should be mat[, "Package", drop=FALSE]. It works fine with other arguments: > installed.packages(lib.loc = "/home/lhansen/R/libs", priority = NULL) Package LibPath Version Priority Bundle Contains Depends test "test" "/home/lhansen/R/libs" "1.0-0" NA NA NA NA Imports Suggests OS_type Built test NA NA NA "2.8.0" and: > installed.packages(lib.loc = "/home/lhansen/R/libs", priority = "high") Package LibPath Version Priority Bundle Contains Depends Imports Suggests OS_type Built The documentation clearly states that "NA" is a valid argument value. It says: To select all packages without an assigned priority use 'priority = "NA"' > sessionInfo() R version 2.8.0 (2008-10-20) x86_64-pc-linux-gnu locale: LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] tools_2.8.0 I ran R with --vanilla. Thanks, Lars From mflawren at fhcrc.org Tue Nov 25 23:38:01 2008 From: mflawren at fhcrc.org (Michael Lawrence) Date: Tue, 25 Nov 2008 14:38:01 -0800 Subject: [Rd] dots methods: dispatch issues Message-ID: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From mflawren at fhcrc.org Tue Nov 25 23:41:57 2008 From: mflawren at fhcrc.org (Michael Lawrence) Date: Tue, 25 Nov 2008 14:41:57 -0800 Subject: [Rd] dots methods: dispatch issues In-Reply-To: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> References: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> Message-ID: <509e0620811251441m6c55dfaaif5b0626dd2930d70@mail.gmail.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From marc_schwartz at comcast.net Wed Nov 26 05:52:34 2008 From: marc_schwartz at comcast.net (Marc Schwartz) Date: Tue, 25 Nov 2008 22:52:34 -0600 Subject: [Rd] Fedora 10, R and yes...help.start()...deja vu all over again... Message-ID: <492CD612.3040000@comcast.net> Hi all, I installed F10 Final today. This was a clean install, not an upgrade from F9. Kudos the the Fedora team as the level of maturity noted in the install process, including using encrypted partitions, keeps getting better with each release. I'd still like to see easier options in the GUI with respect to selecting entire groups of applications, rather than having to go through individual check-boxes. That part of the process took almost as long as the installation itself. Nice also to see the RPMFusion repo fully in place, to centralize the use of multiple former repos (Livna, FreshRPMS, etc.). I built R version 2.8.0 Patched (2008-11-24 r47019) from SVN and have a few observations: 1. F10 is using gcc (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7) 2. R passed 'make check-all' without issue 3. When using the help.start() search engine, the "Applet started." messages appears in the Firefox status line. However, when searching on any term (eg. "plot") the Search Results page shows: No matches for "plot" have been found! Thus, it would appear that the Java-Javascript bridge is still non-functional in the OpenJDK (formerly IcedTea) plugin. The following error messages appear in the R Console when using the search applet with OpenJDK: > ICEDTEAPLUGIN_DEBUG = (null) Initializing JVM... NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Start() JNLPRuntime already initialized NOT IMPLEMENTED: virtual nsresult IcedTeaPluginInstance::Stop() The instructions available here: http://www.mjmwired.net/resources/mjm-fedora-f10.html#java provide a step by step process to get the Sun JRE installed on F10, with one additional step not noted there, required due to SELinux. So follow the steps on the above page. After which, using the search applet you may still see: No matches for "plot" have been found! If you are running SELinux in Enforcing Mode, you may see an AVC error pop-up in the SELinux Troubleshooting Panel Applet. Use the following command: sudo restorecon -v /opt/jre1.6/plugin/i386/ns7/libjavaplugin_oji.so which will re-set the SELinux context for the newly installed Java plug-in file. At that point, if all is well, you should subsequently get proper results from the search applet. You may need to exit from Firefox and use help.start() again just to be sure that any residual issues are not present. If there are any problems, be sure that the 'alternatives' command is configured to use the Sun JRE. This is a two step process: 1. Use: sudo /usr/sbin/alternatives --config java and be sure that /opt/jre1.6/bin/java is selected as designated by the '+': There are 3 programs which provide 'java'. Selection Command ----------------------------------------------- + 1 /usr/lib/jvm/jre-1.6.0-openjdk/bin/java 2 /usr/lib/jvm/jre-1.5.0-gcj/bin/java * 3 /opt/jre1.6/bin/java Enter to keep the current selection[+], or type selection number: 3 2. Use: sudo /usr/sbin/alternatives --config libjavaplugin.so and be sure that '/opt/jre1.6/plugin/i386/ns7/libjavaplugin_oji.so' is selected as designated by the '+': There are 2 programs which provide 'libjavaplugin.so'. Selection Command ----------------------------------------------- + 1 /usr/lib/jvm/jre-1.6.0-openjdk/lib/i386/IcedTeaPlugin.so * 2 /opt/jre1.6/plugin/i386/ns7/libjavaplugin_oji.so Enter to keep the current selection[+], or type selection number: 2 All in all, everything else is going well so far (save of course my ongoing frustration with nVidia, but that's another story for another thread....). Hope that the above is helpful. Off to bed... Regards, Marc Schwartz From jpnolan at american.edu Wed Nov 26 18:17:42 2008 From: jpnolan at american.edu (John Nolan) Date: Wed, 26 Nov 2008 12:17:42 -0500 Subject: [Rd] Rtools28 - undefined references with gfortran Message-ID: An embedded and charset-unspecified text was scrubbed... Name: not available URL: From hb at stat.berkeley.edu Wed Nov 26 20:22:30 2008 From: hb at stat.berkeley.edu (Henrik Bengtsson) Date: Wed, 26 Nov 2008 11:22:30 -0800 Subject: [Rd] file.access() on network (mounted) drive on Windows Vista? Message-ID: <59d7961d0811261122v44f187a8s7f78512d264894bd@mail.gmail.com> Hi, I have a writable and readable file on a small network file system (Cisco NSLU2 Unslung; non-NTFS) that I access via a mounted drive on Windows Vista. My problem could be due to a "funny" file system/server, but here it goes: > pathname <- "Q:/foo.txt" > cat(file=pathname, "Hello world!\n") > readLines(pathname) [1] "Hello world!" > file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 666 2008-11-26 11:45:53 2008-11-26 11:45:53 atime exe Q:/foo.txt 2008-11-26 11:45:57 no The mode == 666 reported by file.info() indicates that it is readable & writable by all users. This is also what Windows Vista file properties reports. So far so good. However, when I use file.access() to test for file permissions, I get: > file.access(pathname, 0) # 0 test for existence. Q:/foo.txt 0 > file.access(pathname, 1) # 1 test for execute permission. Q:/foo.txt -1 > file.access(pathname, 2) # 2 test for write permission. Q:/foo.txt -1 > file.access(pathname, 4) # 4 test for read permission. Q:/foo.txt -1 I obviously can write to and read from the file, and this is what file.info()$mode says too. However, file.access() tells a different story. More troubleshooting: When I log into the file server and do: # chmod ugo-w foo.txt # ls -l foo.txt -r-xr----- 1 admin everyone 14 Nov 26 11:48 foo.txt The changes in permission are seen by file.info(): > file.info(pathname) size isdir mode mtime ctime Q:/foo.txt 14 FALSE 444 2008-11-26 11:48:50 2008-11-26 11:48:50 atime exe Q:/foo.txt 2008-11-26 11:56:40 no The output from file.access() remains the same though. >From help(file.info) I read: File modes are probably only useful on NTFS file systems, and it seems all three digits refer to the file's owner. The execute/search bits are set for directories, and for files based on their extensions (e.g., '.exe', '.com', '.cmd' and '.bat' files). 'file.access' will give a more reliable view of read/write access availability to the R process. >From what I conclude, file.access() is not reliable in this case. Is this a feature or a bug? I need a cross-platform test for file permissions, and I am looking for safer workaround. For instance, could it be that a zero result from file.access() can be trusted, but a -1 could occur either from a true lack of permission as well as a failure to test for the permission? If that would be case, I could try other measures (e.g. try to open the file) whenever I receive a -1 before throwing an exception. Any feedback or suggestions would be great. Thanks /Henrik > sessionInfo() R version 2.8.0 Patched (2008-10-21 r46766) i386-pc-mingw32 locale: LC_COLLATE=English_United States.1252;LC_CTYPE=English_United States.1252;LC_MON ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base From jmc at r-project.org Wed Nov 26 21:31:22 2008 From: jmc at r-project.org (John Chambers) Date: Wed, 26 Nov 2008 12:31:22 -0800 Subject: [Rd] dots methods: dispatch issues In-Reply-To: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> References: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> Message-ID: <492DB21A.6040202@r-project.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From jmc at r-project.org Wed Nov 26 23:52:46 2008 From: jmc at r-project.org (John Chambers) Date: Wed, 26 Nov 2008 14:52:46 -0800 Subject: [Rd] dots methods: dispatch issues In-Reply-To: <492DB21A.6040202@r-project.org> References: <509e0620811251438i370c12c5vbe75fadc1fa1ec0c@mail.gmail.com> <492DB21A.6040202@r-project.org> Message-ID: <492DD33E.2040701@r-project.org> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From maechler at stat.math.ethz.ch Thu Nov 27 12:20:15 2008 From: maechler at stat.math.ethz.ch (maechler at stat.math.ethz.ch) Date: Thu, 27 Nov 2008 12:20:15 +0100 (CET) Subject: [Rd] Problem with installed.packages (PR#13332) Message-ID: <20081127112015.3E711282C774@mail.pubhealth.ku.dk> >>>>> "LH" == lhansen >>>>> on Tue, 25 Nov 2008 23:30:23 +0100 (CET) writes: LH> Full_Name: Lars Hansen LH> Version: 2.8.0 LH> OS: Linux LH> Submission from: (NULL) (70.90.201.133) LH> Hi, LH> Calling installed.packages() on a directory with only one package causes an LH> error if the priority argument is set to "NA": >> installed.packages(lib.loc = "/home/lhansen/R/libs", priority = "NA") LH> Error in mat[, "Package"] : incorrect number of dimensions LH> This seems like a classic dropping from matrix to vector bug. Yes, indeed, it is : forgetting to use ', drop = FALSE' LH> Maybe the code LH> should be mat[, "Package", drop=FALSE]. no, it's here : mat <- mat[keep, , drop=FALSE] This will be fixed in R-devel and R-patched within the next few hours. Thank you very much, Lars, for the bug report! Martin Maechler, ETH Zurich From hkawakat at gmail.com Thu Nov 27 13:12:33 2008 From: hkawakat at gmail.com (Hiroyuki Kawakatsu) Date: Thu, 27 Nov 2008 12:12:33 +0000 Subject: [Rd] make fails with no rule to make target `VR.ts' In-Reply-To: <307b90470811240701q3e7c6244u7e58ef7de8d72969@mail.gmail.com> References: <307b90470811240701q3e7c6244u7e58ef7de8d72969@mail.gmail.com> Message-ID: <307b90470811270412ud48b8e1m8f564b3a03545280@mail.gmail.com> On Mon, Nov 24, 2008 at 3:01 PM, I wrote: > When trying to build R-devel.tar.bz2 (SVN-REVISION: 47015) I am > getting the error: > [...] > gmake[2]: *** No rule to make target `VR.ts', needed by > `stamp-recommended'. Stop. [...] > This is on FreeBSD 7.0-RELEASE (amd64) with > > ./configure MAKE=gmake CC=gcc44 F77=gfortran44 FC=gfortran44 CXX=g++44 > OBJC=gcc44 R_BROWSER=/usr/local/bin/firefox3 > > This used to build fine until a few weeks ago. Any hints for what may > be going wrong? I have finally tracked down the source of error. A diff between the 2008-11-18-2008 (builds ok) and 2008-11-19 (build fails as above) tar balls shows that the *.tgz link files are missing in R_HOME/src/library/Recommended/ in the latter tar ball. Once I manually created the links, gmake runs fine. Is this an omission or something to do with the way I am unpacking the tar balls? (I presume most people who build R-devel simply check out from trunk?) h. -- +--- | Hiroyuki Kawakatsu | Business School, Dublin City University | Dublin 9, Ireland. Tel +353 (0)1 700 7496 From asherman at ksu.ru Thu Nov 27 14:30:04 2008 From: asherman at ksu.ru (asherman at ksu.ru) Date: Thu, 27 Nov 2008 14:30:04 +0100 (CET) Subject: [Rd] A small bug in R code of the legend function of the Graphics pacakge (PR#13340) Message-ID: <20081127133004.A4BF6282BEBF@mail.pubhealth.ku.dk> Full_Name: Arkady Sherman Version: 2.8.0 OS: Windows XP Submission from: (NULL) (158.195.16.114) Please consider initialization of the "seg.len" variable. It's done only if (do.lines) { seg.len <- 2 .., but after the seg.len is used: if (has.pch) { pch <- rep(pch, length.out = n.leg) pt.bg <- rep(pt.bg, length.out = n.leg) pt.cex <- rep(pt.cex, length.out = n.leg) pt.lwd <- rep(pt.lwd, length.out = n.leg) ok <- !is.na(pch) & (is.character(pch) | pch >= 0) x1 <- (if (merge) xt - (seg.len/2) * xchar so if do.lines isn't specified, but has.pch and merge are specified an error is produced. Guess that seg.len should be initialized before the condition "if (do.lines)" Thanks in advance. From spluque at gmail.com Thu Nov 27 16:35:04 2008 From: spluque at gmail.com (spluque at gmail.com) Date: Thu, 27 Nov 2008 16:35:04 +0100 (CET) Subject: [Rd] missing parentheses in FAQ (PR#13343) Message-ID: <20081127153504.8E3152834615@mail.pubhealth.ku.dk> Hi, A couple of missing parenthesis in R-devel's FAQ: ---<---------------cut here---------------start-------------->--- Index: doc/manual/R-FAQ.texi =================================================================== --- doc/manual/R-FAQ.texi (revision 47025) +++ doc/manual/R-FAQ.texi (working copy) @@ -7962,7 +7962,7 @@ @example eval(substitute(lm(y ~ x + variable), - list(variable = as.name(varname[1])) + list(variable = as.name(varname[1])))) @end example @noindent ---<---------------cut here---------------end---------------->--- Cheers, -- Seb From vogranovich at jumptrading.com Fri Nov 28 20:03:49 2008 From: vogranovich at jumptrading.com (Vadim Ogranovich) Date: Fri, 28 Nov 2008 13:03:49 -0600 Subject: [Rd] names generated in list indexing Message-ID: <22D850BC39A25742977325ADDE208E770270618DAB@chiexchange02.w2k.jumptrading.com> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From ecg503 at york.ac.uk Fri Nov 28 15:55:10 2008 From: ecg503 at york.ac.uk (ecg503 at york.ac.uk) Date: Fri, 28 Nov 2008 15:55:10 +0100 (CET) Subject: [Rd] Unable to plot or analyse phylogeny (PR#13345) Message-ID: <20081128145510.75BE0282EFF6@mail.pubhealth.ku.dk> Full_Name: Emily Green Version: 2.8.0 GUI 1.26 OS: MacBrook Pro with 2.5 GHz processor, using Mac OS X 10.5.5 Submission from: (NULL) (144.32.69.137) I am wanting to correct for phylogeny using a phylogenetic tree of 296 birds species, which I have constructed myself. The file format is correct and I have checked its display in Mesquite, which exported the nexus file (I've pasted the text of the file at the end of this message, the matrices are purposefully blank). As a text file this looks absolutely fine to me. R can at least read the tree fine using read.tree to produce the following: > sa<-read.nexus("sa_r.txt.nex") > summary(sa) Phylogenetic tree: sa Number of tips: 296 Number of nodes: 239 Branch lengths: mean: NA variance: NA distribution summary: Min. 1st Qu. Median 3rd Qu. Max. NA's 8.00e-202 8.00e-202 2.00e+00 5.00e+00 2.63e+01 3.00e+00 Root edge: 1.1 First ten tip labels: Alectoris_barbara Alectoris_chuckar Alectoris_graeca Ammoperdix_griseogularis Bonasa_Bonasia Francolinus_francolinus Tetrao_mlokosiewiczi Tetraogallus_caspius Tetraogallus_caucasiucus Anser_albifrons First ten node labels: 0 0 0 0 0 0 0 0 0 0 I was a bit worried as to why no mean or variance of branch length was produced, when these are all present in the nexus file and Mesquite can recognise them. But I proceeded to attempt to plot the tree in R to check it displayed correctly here. This is something I've done before in R with smaller trees and it worked fine. But with this tree it produced the following error: > plot.phylo(sa) Error: cannot allocate vector of size 1.4 Gb R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug The same problem comes up when I try to run an autocorrelative model with some dummy continuous data. (I've tried many different functions, all produce similar error responses): > Moran.I(dummy$dist, cophenetic(sa)) Error: cannot allocate vector of size 1.4 Gb R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug I fear my tree may be too big to handle, but this is my dataset and I wanted to make use of the range and power of R's analytical capabilites over other programs like Mesquite. If you can solve my problem I'd be very very grateful. Cheers, Emily PS - the text of the nexus file #NEXUS [written Thu Nov 27 17:49:33 GMT 2008 by Mesquite version 2.5 (build j77) at sns69-198.york.ac.uk/144.32.69.198] BEGIN TAXA; TITLE Taxa; DIMENSIONS NTAX=296; TAXLABELS Alectoris_barbara Alectoris_chuckar Alectoris_graeca Ammoperdix_griseogularis Bonasa_Bonasia Francolinus_francolinus Tetrao_mlokosiewiczi Tetraogallus_caspius Tetraogallus_caucasiucus Anser_albifrons Anser_brachyrhynchus Anser_erythropus Anser_fabalis Aythya_marila Aythya_nyroca Branta_bernicla Branta_canadensis Branta_leucopsis Branta_ruficollis Bucephala_islandica Chen_caerulescens Clangula_hyemalis Cygnus_columbianus Cygnus_cygnus Histrionicus_histrionicus Marmaronetta_angustirostris Melanitta_fusca Melanitta_perspicillata Netta_rufina Oxyura_leucocephala Polysticta_stelleri Somateria_spectabilis Tadorna_ferruginea Dendrocopos_leucotos Dendrocopos_medius Dendrocopos_syriacus Dryocopus_martius Jynx_torquilla Picoides_tridactylus Picus_canus Upupa_epops Coracias_garrulus Merops_apiaster Merops_persicus Ceryle_rudis Halcyon_smyrnensis Cuculus_optatus Apus_affinis Apus_caffer Apus_pallidus Apus_unicolor Tachymarptis_melba Aegolius_funereus Bubo_bubo Bubo_scandiaca Glaucidium_passerinum Ketupa_zeylonensis Otus_brucei Otus_scops Strix_nebulosa Strix_uralensis Surnia_ulula Caprimulgus_ruficollis Columba_bollii Columba_junoniae Columba_trocaz Stigmatopelia_senegalensis Chlamydotis_undulata Otis_tarda Tetrax_tetrax Grus_grus Grus_virgo Fulica_cristata Porphyrio_porphyrio Porzana_parva Porzana_pusilla Pterocles_alchata Pterocles_orientalis Arenaria_interpres Calidris_alba Calidris_bairdii Calidris_maritima Calidris_temminckii Gallinago_media Limicola_falcinellus Limosa_lapponica Lymnocryptes_minimus Phalaropus_fulicarius Tringa_erythropus Tringa_glareola Tringa_ochropus Tringa_stagnatilis Xenus_cinereus Charadrius_alexandrinus Charadrius_asiaticus Charadrius_leschenaultii Vanellus_indicus Vanellus_spinosus Cursorius_cursor Glareola_nordmanni Glareola_pratincola Larus_armenicus Larus_audouinii Larus_genei Larus_glaucoides Larus_hyperboreus Larus_ichthyaetus Larus_minutus Pagophila_eburnea Accipiter_badius Accipiter_brevipes Aegypius_monachus Aquila_adalberti Aquila_clanga Aquila_heliaca Aquila_nipalensis Aquila_pomarina Buteo_lagopus Buteo_rufinus Circaetus_gallicus Circus_macrourus Circus_pygargus Elanus_caeruleus Gypaetus_barbatus Gyps_fulvus Hieraaetus_fasciatus Hieraaetus_pennatus Milvus_migrans Neophron_percnopterus Alle_alle Uria_lomvia Himantopus_himantopus Falco_biarmicus Falco_cherrug Falco_eleonorae Falco_naumanni Falco_pelerinoides Falco_rusticolus Falco_vespertinus Podiceps_grisegena Phaethon_aethereus Phalacrocorax_pygmeus Ardea_purpurea Ardeola_ralloides Bubulcus_ibis Egretta_alba Ixobrychus_minutus Nycticorax_nycticorax Phoenicopterus_ruber Platalea_leucorodia Plegadis_falcinellus Pelecanus_crispus Pelecanus_onocrotalus Ciconia_ciconia Ciconia_nigra Fregata_magnificens Gavia_immer Oceanites_oceanicus Pelagodroma_marina Bulweria_bulwerii Calonectris_diomedea Pterodroma_feae Pterodroma_madeira Puffinus_assimilis Puffinus_gravis Puffinus_griseus Puffinus_mauretanicus Puffinus_yelkouan Lanius_collurio Lanius_excubitor Lanius_isabellinus Lanius_minor Lanius_nubicus Lanius_senator Cyanopica_cyanus Nucifraga_caryocatactes Perisoreus_infaustus Pyrrhocorax_graculus Sturnus_roseus Sturnus_unicolor Bombycilla_garrulus Cercotrichas_galactotes Ficedula_albicollis Ficedula_parva Chlidonias_hybrida Chlidonias_leucopterus Chlidonias_niger Sterna_caspia Sitta_krueperi Sitta_neumayer Sitta_whiteheadi Certhia_brachydactyla Parus_cinctus Parus_cyanus Parus_lugubris Hirundo_daurica Hirundo_rupestris Pycnonotus_xanthopygos Cisticola_juncidis Prinia_gracilis Luscinia_calliope Luscinia_luscinia Luscinia_svecica Monticola_saxatilis Monticola_solitarius Oenanthe_deserti Oenanthe_finschii Oenanthe_hispanica Oenanthe_isabellina Oenanthe_leucura Oenanthe_pleschanka Oenanthe_xanthoprymna Tarsiger_cyanurus Turdus_ruficollis Acrocephalus_agricola Acrocephalus_arundinaceus Acrocephalus_dumetorum Acrocephalus_melanopogon Acrocephalus_paludicola Hippolais_caligata Hippolais_icterina Hippolais_languida Hippolais_olivetorum Hippolais_opaca Hippolais_pallida Hippolais_polyglotta Locustella_lanceolata Locustella_luscinioides Phylloscopus_bonelli Phylloscopus_borealis Phylloscopus_canariensis Phylloscopus_fuscatus Phylloscopus_ibericus Phylloscopus_inornatus Phylloscopus_sindianus Phylloscopus_trochiloides Sylvia_cantillans Sylvia_conspicillata Sylvia_hortensis Sylvia_melanocephala Sylvia_melanothorax Sylvia_mystacea Sylvia_nana Sylvia_nisoria Sylvia_rueppelli Sylvia_sarda Ammomanes_deserti Calandrella_brachydactyla Calandrella_rufescens Chersophilus_duponti Eremophila_alpestris Galerida_cristata Galerida_theklae Melanocorypha_bimaculata Melanocorypha_calandra Melanocorypha_leucoptera Melanocorypha_yeltoniensis Montifringilla_nivalis Passer_hispaniolensis Petronia_petronia Bucanetes_githagineus Carduelis_hornemanni Carpodacus_erythrinus Carpodacus_rubicilla Loxia_leucoptera Loxia_pytyopsittacus Pinicola_enucleator Pyrrhula_murina Rhodopechys_mongolicus Serinus_canaria Serinus_citrinella Serinus_pusillus Serinus_serinus Tichodroma_muraria Remiz_pendulinus Prunella_atrogularis Prunella_collaris Prunella_montanella Anthus_berthelotii Anthus_campestris Anthus_cervinus Anthus_hodgsoni Anthus_spinoletta Motacilla_citreola Calcarius_lapponicus Emberiza_aureola Emberiza_bruniceps Emberiza_caesia Emberiza_cia Emberiza_cineracea Emberiza_hortulana Emberiza_leucocephalos Emberiza_melanocephala Emberiza_pallasi Emberiza_pusilla Emberiza_rustica ; END; BEGIN CHARACTERS; TITLE Categorical; DIMENSIONS NCHAR=7; FORMAT DATATYPE = STANDARD GAP = - MISSING = ? SYMBOLS = " 0 1"; MATRIX Alectoris_barbara ??????? Alectoris_chuckar ??????? Alectoris_graeca ??????? Ammoperdix_griseogularis ??????? Bonasa_Bonasia ??????? Francolinus_francolinus ??????? Tetrao_mlokosiewiczi ??????? Tetraogallus_caspius ??????? Tetraogallus_caucasiucus ??????? Anser_albifrons ??????? Anser_brachyrhynchus ??????? Anser_erythropus ??????? Anser_fabalis ??????? Aythya_marila ??????? Aythya_nyroca ??????? Branta_bernicla ??????? Branta_canadensis ??????? Branta_leucopsis ??????? Branta_ruficollis ??????? Bucephala_islandica ??????? Chen_caerulescens ??????? Clangula_hyemalis ??????? Cygnus_columbianus ??????? Cygnus_cygnus ??????? Histrionicus_histrionicus ??????? Marmaronetta_angustirostris ??????? Melanitta_fusca ??????? Melanitta_perspicillata ??????? Netta_rufina ??????? Oxyura_leucocephala ??????? Polysticta_stelleri ??????? Somateria_spectabilis ??????? Tadorna_ferruginea ??????? Dendrocopos_leucotos ??????? Dendrocopos_medius ??????? Dendrocopos_syriacus ??????? Dryocopus_martius ??????? Jynx_torquilla ??????? Picoides_tridactylus ??????? Picus_canus ??????? Upupa_epops ??????? Coracias_garrulus ??????? Merops_apiaster ??????? Merops_persicus ??????? Ceryle_rudis ??????? Halcyon_smyrnensis ??????? Cuculus_optatus ??????? Apus_affinis ??????? Apus_caffer ??????? Apus_pallidus ??????? Apus_unicolor ??????? Tachymarptis_melba ??????? Aegolius_funereus ??????? Bubo_bubo ??????? Bubo_scandiaca ??????? Glaucidium_passerinum ??????? Ketupa_zeylonensis ??????? Otus_brucei ??????? Otus_scops ??????? Strix_nebulosa ??????? Strix_uralensis ??????? Surnia_ulula ??????? Caprimulgus_ruficollis ??????? Columba_bollii ??????? Columba_junoniae ??????? Columba_trocaz ??????? Stigmatopelia_senegalensis ??????? Chlamydotis_undulata ??????? Otis_tarda ??????? Tetrax_tetrax ??????? Grus_grus ??????? Grus_virgo ??????? Fulica_cristata ??????? Porphyrio_porphyrio ??????? Porzana_parva ??????? Porzana_pusilla ??????? Pterocles_alchata ??????? Pterocles_orientalis ??????? Arenaria_interpres ??????? Calidris_alba ??????? Calidris_bairdii ??????? Calidris_maritima ??????? Calidris_temminckii ??????? Gallinago_media ??????? Limicola_falcinellus ??????? Limosa_lapponica ??????? Lymnocryptes_minimus ??????? Phalaropus_fulicarius ??????? Tringa_erythropus ??????? Tringa_glareola ??????? Tringa_ochropus ??????? Tringa_stagnatilis ??????? Xenus_cinereus ??????? Charadrius_alexandrinus ??????? Charadrius_asiaticus ??????? Charadrius_leschenaultii ??????? Vanellus_indicus ??????? Vanellus_spinosus ??????? Cursorius_cursor ??????? Glareola_nordmanni ??????? Glareola_pratincola ??????? Larus_armenicus ??????? Larus_audouinii ??????? Larus_genei ??????? Larus_glaucoides ??????? Larus_hyperboreus ??????? Larus_ichthyaetus ??????? Larus_minutus ??????? Pagophila_eburnea ??????? Accipiter_badius ??????? Accipiter_brevipes ??????? Aegypius_monachus ??????? Aquila_adalberti ??????? Aquila_clanga ??????? Aquila_heliaca ??????? Aquila_nipalensis ??????? Aquila_pomarina ??????? Buteo_lagopus ??????? Buteo_rufinus ??????? Circaetus_gallicus ??????? Circus_macrourus ??????? Circus_pygargus ??????? Elanus_caeruleus ??????? Gypaetus_barbatus ??????? Gyps_fulvus ??????? Hieraaetus_fasciatus ??????? Hieraaetus_pennatus ??????? Milvus_migrans ??????? Neophron_percnopterus ??????? Alle_alle ??????? Uria_lomvia ??????? Himantopus_himantopus ??????? Falco_biarmicus ??????? Falco_cherrug ??????? Falco_eleonorae ??????? Falco_naumanni ??????? Falco_pelerinoides ??????? Falco_rusticolus ??????? Falco_vespertinus ??????? Podiceps_grisegena ??????? Phaethon_aethereus ??????? Phalacrocorax_pygmeus ??????? Ardea_purpurea ??????? Ardeola_ralloides ??????? Bubulcus_ibis ??????? Egretta_alba ??????? Ixobrychus_minutus ??????? Nycticorax_nycticorax ??????? Phoenicopterus_ruber ??????? Platalea_leucorodia ??????? Plegadis_falcinellus ??????? Pelecanus_crispus ??????? Pelecanus_onocrotalus ??????? Ciconia_ciconia ??????? Ciconia_nigra ??????? Fregata_magnificens ??????? Gavia_immer ??????? Oceanites_oceanicus ??????? Pelagodroma_marina ??????? Bulweria_bulwerii ??????? Calonectris_diomedea ??????? Pterodroma_feae ??????? Pterodroma_madeira ??????? Puffinus_assimilis ??????? Puffinus_gravis ??????? Puffinus_griseus ??????? Puffinus_mauretanicus ??????? Puffinus_yelkouan ??????? Lanius_collurio ??????? Lanius_excubitor ??????? Lanius_isabellinus ??????? Lanius_minor ??????? Lanius_nubicus ??????? Lanius_senator ??????? Cyanopica_cyanus ??????? Nucifraga_caryocatactes ??????? Perisoreus_infaustus ??????? Pyrrhocorax_graculus ??????? Sturnus_roseus ??????? Sturnus_unicolor ??????? Bombycilla_garrulus ??????? Cercotrichas_galactotes ??????? Ficedula_albicollis ??????? Ficedula_parva ??????? Chlidonias_hybrida ??????? Chlidonias_leucopterus ??????? Chlidonias_niger ??????? Sterna_caspia ??????? Sitta_krueperi ??????? Sitta_neumayer ??????? Sitta_whiteheadi ??????? Certhia_brachydactyla ??????? Parus_cinctus ??????? Parus_cyanus ??????? Parus_lugubris ??????? Hirundo_daurica ??????? Hirundo_rupestris ??????? Pycnonotus_xanthopygos ??????? Cisticola_juncidis ??????? Prinia_gracilis ??????? Luscinia_calliope ??????? Luscinia_luscinia ??????? Luscinia_svecica ??????? Monticola_saxatilis ??????? Monticola_solitarius ??????? Oenanthe_deserti ??????? Oenanthe_finschii ??????? Oenanthe_hispanica ??????? Oenanthe_isabellina ??????? Oenanthe_leucura ??????? Oenanthe_pleschanka ??????? Oenanthe_xanthoprymna ??????? Tarsiger_cyanurus ??????? Turdus_ruficollis ??????? Acrocephalus_agricola ??????? Acrocephalus_arundinaceus ??????? Acrocephalus_dumetorum ??????? Acrocephalus_melanopogon ??????? Acrocephalus_paludicola ??????? Hippolais_caligata ??????? Hippolais_icterina ??????? Hippolais_languida ??????? Hippolais_olivetorum ??????? Hippolais_opaca ??????? Hippolais_pallida ??????? Hippolais_polyglotta ??????? Locustella_lanceolata ??????? Locustella_luscinioides ??????? Phylloscopus_bonelli ??????? Phylloscopus_borealis ??????? Phylloscopus_canariensis ??????? Phylloscopus_fuscatus ??????? Phylloscopus_ibericus ??????? Phylloscopus_inornatus ??????? Phylloscopus_sindianus ??????? Phylloscopus_trochiloides ??????? Sylvia_cantillans ??????? Sylvia_conspicillata ??????? Sylvia_hortensis ??????? Sylvia_melanocephala ??????? Sylvia_melanothorax ??????? Sylvia_mystacea ??????? Sylvia_nana ??????? Sylvia_nisoria ??????? Sylvia_rueppelli ??????? Sylvia_sarda ??????? Ammomanes_deserti ??????? Calandrella_brachydactyla ??????? Calandrella_rufescens ??????? Chersophilus_duponti ??????? Eremophila_alpestris ??????? Galerida_cristata ??????? Galerida_theklae ??????? Melanocorypha_bimaculata ??????? Melanocorypha_calandra ??????? Melanocorypha_leucoptera ??????? Melanocorypha_yeltoniensis ??????? Montifringilla_nivalis ??????? Passer_hispaniolensis ??????? Petronia_petronia ??????? Bucanetes_githagineus ??????? Carduelis_hornemanni ??????? Carpodacus_erythrinus ??????? Carpodacus_rubicilla ??????? Loxia_leucoptera ??????? Loxia_pytyopsittacus ??????? Pinicola_enucleator ??????? Pyrrhula_murina ??????? Rhodopechys_mongolicus ??????? Serinus_canaria ??????? Serinus_citrinella ??????? Serinus_pusillus ??????? Serinus_serinus ??????? Tichodroma_muraria ??????? Remiz_pendulinus ??????? Prunella_atrogularis ??????? Prunella_collaris ??????? Prunella_montanella ??????? Anthus_berthelotii ??????? Anthus_campestris ??????? Anthus_cervinus ??????? Anthus_hodgsoni ??????? Anthus_spinoletta ??????? Motacilla_citreola ??????? Calcarius_lapponicus ??????? Emberiza_aureola ??????? Emberiza_bruniceps ??????? Emberiza_caesia ??????? Emberiza_cia ??????? Emberiza_cineracea ??????? Emberiza_hortulana ??????? Emberiza_leucocephalos ??????? Emberiza_melanocephala ??????? Emberiza_pallasi ??????? Emberiza_pusilla ??????? Emberiza_rustica ??????? ; END; BEGIN CHARACTERS; TITLE Continuous; DIMENSIONS NCHAR=10; FORMAT DATATYPE = CONTINUOUS GAP = - MISSING = ?; MATRIX Alectoris_barbara ? ? ? ? ? ? ? ? ? ? Alectoris_chuckar ? ? ? ? ? ? ? ? ? ? Alectoris_graeca ? ? ? ? ? ? ? ? ? ? Ammoperdix_griseogularis ? ? ? ? ? ? ? ? ? ? Bonasa_Bonasia ? ? ? ? ? ? ? ? ? ? Francolinus_francolinus ? ? ? ? ? ? ? ? ? ? Tetrao_mlokosiewiczi ? ? ? ? ? ? ? ? ? ? Tetraogallus_caspius ? ? ? ? ? ? ? ? ? ? Tetraogallus_caucasiucus ? ? ? ? ? ? ? ? ? ? Anser_albifrons ? ? ? ? ? ? ? ? ? ? Anser_brachyrhynchus ? ? ? ? ? ? ? ? ? ? Anser_erythropus ? ? ? ? ? ? ? ? ? ? Anser_fabalis ? ? ? ? ? ? ? ? ? ? Aythya_marila ? ? ? ? ? ? ? ? ? ? Aythya_nyroca ? ? ? ? ? ? ? ? ? ? Branta_bernicla ? ? ? ? ? ? ? ? ? ? Branta_canadensis ? ? ? ? ? ? ? ? ? ? Branta_leucopsis ? ? ? ? ? ? ? ? ? ? Branta_ruficollis ? ? ? ? ? ? ? ? ? ? Bucephala_islandica ? ? ? ? ? ? ? ? ? ? Chen_caerulescens ? ? ? ? ? ? ? ? ? ? Clangula_hyemalis ? ? ? ? ? ? ? ? ? ? Cygnus_columbianus ? ? ? ? ? ? ? ? ? ? Cygnus_cygnus ? ? ? ? ? ? ? ? ? ? Histrionicus_histrionicus ? ? ? ? ? ? ? ? ? ? Marmaronetta_angustirostris ? ? ? ? ? ? ? ? ? ? Melanitta_fusca ? ? ? ? ? ? ? ? ? ? Melanitta_perspicillata ? ? ? ? ? ? ? ? ? ? Netta_rufina ? ? ? ? ? ? ? ? ? ? Oxyura_leucocephala ? ? ? ? ? ? ? ? ? ? Polysticta_stelleri ? ? ? ? ? ? ? ? ? ? Somateria_spectabilis ? ? ? ? ? ? ? ? ? ? Tadorna_ferruginea ? ? ? ? ? ? ? ? ? ? Dendrocopos_leucotos ? ? ? ? ? ? ? ? ? ? Dendrocopos_medius ? ? ? ? ? ? ? ? ? ? Dendrocopos_syriacus ? ? ? ? ? ? ? ? ? ? Dryocopus_martius ? ? ? ? ? ? ? ? ? ? Jynx_torquilla ? ? ? ? ? ? ? ? ? ? Picoides_tridactylus ? ? ? ? ? ? ? ? ? ? Picus_canus ? ? ? ? ? ? ? ? ? ? Upupa_epops ? ? ? ? ? ? ? ? ? ? Coracias_garrulus ? ? ? ? ? ? ? ? ? ? Merops_apiaster ? ? ? ? ? ? ? ? ? ? Merops_persicus ? ? ? ? ? ? ? ? ? ? Ceryle_rudis ? ? ? ? ? ? ? ? ? ? Halcyon_smyrnensis ? ? ? ? ? ? ? ? ? ? Cuculus_optatus ? ? ? ? ? ? ? ? ? ? Apus_affinis ? ? ? ? ? ? ? ? ? ? Apus_caffer ? ? ? ? ? ? ? ? ? ? Apus_pallidus ? ? ? ? ? ? ? ? ? ? Apus_unicolor ? ? ? ? ? ? ? ? ? ? Tachymarptis_melba ? ? ? ? ? ? ? ? ? ? Aegolius_funereus ? ? ? ? ? ? ? ? ? ? Bubo_bubo ? ? ? ? ? ? ? ? ? ? Bubo_scandiaca ? ? ? ? ? ? ? ? ? ? Glaucidium_passerinum ? ? ? ? ? ? ? ? ? ? Ketupa_zeylonensis ? ? ? ? ? ? ? ? ? ? Otus_brucei ? ? ? ? ? ? ? ? ? ? Otus_scops ? ? ? ? ? ? ? ? ? ? Strix_nebulosa ? ? ? ? ? ? ? ? ? ? Strix_uralensis ? ? ? ? ? ? ? ? ? ? Surnia_ulula ? ? ? ? ? ? ? ? ? ? Caprimulgus_ruficollis ? ? ? ? ? ? ? ? ? ? Columba_bollii ? ? ? ? ? ? ? ? ? ? Columba_junoniae ? ? ? ? ? ? ? ? ? ? Columba_trocaz ? ? ? ? ? ? ? ? ? ? Stigmatopelia_senegalensis ? ? ? ? ? ? ? ? ? ? Chlamydotis_undulata ? ? ? ? ? ? ? ? ? ? Otis_tarda ? ? ? ? ? ? ? ? ? ? Tetrax_tetrax ? ? ? ? ? ? ? ? ? ? Grus_grus ? ? ? ? ? ? ? ? ? ? Grus_virgo ? ? ? ? ? ? ? ? ? ? Fulica_cristata ? ? ? ? ? ? ? ? ? ? Porphyrio_porphyrio ? ? ? ? ? ? ? ? ? ? Porzana_parva ? ? ? ? ? ? ? ? ? ? Porzana_pusilla ? ? ? ? ? ? ? ? ? ? Pterocles_alchata ? ? ? ? ? ? ? ? ? ? Pterocles_orientalis ? ? ? ? ? ? ? ? ? ? Arenaria_interpres ? ? ? ? ? ? ? ? ? ? Calidris_alba ? ? ? ? ? ? ? ? ? ? Calidris_bairdii ? ? ? ? ? ? ? ? ? ? Calidris_maritima ? ? ? ? ? ? ? ? ? ? Calidris_temminckii ? ? ? ? ? ? ? ? ? ? Gallinago_media ? ? ? ? ? ? ? ? ? ? Limicola_falcinellus ? ? ? ? ? ? ? ? ? ? Limosa_lapponica ? ? ? ? ? ? ? ? ? ? Lymnocryptes_minimus ? ? ? ? ? ? ? ? ? ? Phalaropus_fulicarius ? ? ? ? ? ? ? ? ? ? Tringa_erythropus ? ? ? ? ? ? ? ? ? ? Tringa_glareola ? ? ? ? ? ? ? ? ? ? Tringa_ochropus ? ? ? ? ? ? ? ? ? ? Tringa_stagnatilis ? ? ? ? ? ? ? ? ? ? Xenus_cinereus ? ? ? ? ? ? ? ? ? ? Charadrius_alexandrinus ? ? ? ? ? ? ? ? ? ? Charadrius_asiaticus ? ? ? ? ? ? ? ? ? ? Charadrius_leschenaultii ? ? ? ? ? ? ? ? ? ? Vanellus_indicus ? ? ? ? ? ? ? ? ? ? Vanellus_spinosus ? ? ? ? ? ? ? ? ? ? Cursorius_cursor ? ? ? ? ? ? ? ? ? ? Glareola_nordmanni ? ? ? ? ? ? ? ? ? ? Glareola_pratincola ? ? ? ? ? ? ? ? ? ? Larus_armenicus ? ? ? ? ? ? ? ? ? ? Larus_audouinii ? ? ? ? ? ? ? ? ? ? Larus_genei ? ? ? ? ? ? ? ? ? ? Larus_glaucoides ? ? ? ? ? ? ? ? ? ? Larus_hyperboreus ? ? ? ? ? ? ? ? ? ? Larus_ichthyaetus ? ? ? ? ? ? ? ? ? ? Larus_minutus ? ? ? ? ? ? ? ? ? ? Pagophila_eburnea ? ? ? ? ? ? ? ? ? ? Accipiter_badius ? ? ? ? ? ? ? ? ? ? Accipiter_brevipes ? ? ? ? ? ? ? ? ? ? Aegypius_monachus ? ? ? ? ? ? ? ? ? ? Aquila_adalberti ? ? ? ? ? ? ? ? ? ? Aquila_clanga ? ? ? ? ? ? ? ? ? ? Aquila_heliaca ? ? ? ? ? ? ? ? ? ? Aquila_nipalensis ? ? ? ? ? ? ? ? ? ? Aquila_pomarina ? ? ? ? ? ? ? ? ? ? Buteo_lagopus ? ? ? ? ? ? ? ? ? ? Buteo_rufinus ? ? ? ? ? ? ? ? ? ? Circaetus_gallicus ? ? ? ? ? ? ? ? ? ? Circus_macrourus ? ? ? ? ? ? ? ? ? ? Circus_pygargus ? ? ? ? ? ? ? ? ? ? Elanus_caeruleus ? ? ? ? ? ? ? ? ? ? Gypaetus_barbatus ? ? ? ? ? ? ? ? ? ? Gyps_fulvus ? ? ? ? ? ? ? ? ? ? Hieraaetus_fasciatus ? ? ? ? ? ? ? ? ? ? Hieraaetus_pennatus ? ? ? ? ? ? ? ? ? ? Milvus_migrans ? ? ? ? ? ? ? ? ? ? Neophron_percnopterus ? ? ? ? ? ? ? ? ? ? Alle_alle ? ? ? ? ? ? ? ? ? ? Uria_lomvia ? ? ? ? ? ? ? ? ? ? Himantopus_himantopus ? ? ? ? ? ? ? ? ? ? Falco_biarmicus ? ? ? ? ? ? ? ? ? ? Falco_cherrug ? ? ? ? ? ? ? ? ? ? Falco_eleonorae ? ? ? ? ? ? ? ? ? ? Falco_naumanni ? ? ? ? ? ? ? ? ? ? Falco_pelerinoides ? ? ? ? ? ? ? ? ? ? Falco_rusticolus ? ? ? ? ? ? ? ? ? ? Falco_vespertinus ? ? ? ? ? ? ? ? ? ? Podiceps_grisegena ? ? ? ? ? ? ? ? ? ? Phaethon_aethereus ? ? ? ? ? ? ? ? ? ? Phalacrocorax_pygmeus ? ? ? ? ? ? ? ? ? ? Ardea_purpurea ? ? ? ? ? ? ? ? ? ? Ardeola_ralloides ? ? ? ? ? ? ? ? ? ? Bubulcus_ibis ? ? ? ? ? ? ? ? ? ? Egretta_alba ? ? ? ? ? ? ? ? ? ? Ixobrychus_minutus ? ? ? ? ? ? ? ? ? ? Nycticorax_nycticorax ? ? ? ? ? ? ? ? ? ? Phoenicopterus_ruber ? ? ? ? ? ? ? ? ? ? Platalea_leucorodia ? ? ? ? ? ? ? ? ? ? Plegadis_falcinellus ? ? ? ? ? ? ? ? ? ? Pelecanus_crispus ? ? ? ? ? ? ? ? ? ? Pelecanus_onocrotalus ? ? ? ? ? ? ? ? ? ? Ciconia_ciconia ? ? ? ? ? ? ? ? ? ? Ciconia_nigra ? ? ? ? ? ? ? ? ? ? Fregata_magnificens ? ? ? ? ? ? ? ? ? ? Gavia_immer ? ? ? ? ? ? ? ? ? ? Oceanites_oceanicus ? ? ? ? ? ? ? ? ? ? Pelagodroma_marina ? ? ? ? ? ? ? ? ? ? Bulweria_bulwerii ? ? ? ? ? ? ? ? ? ? Calonectris_diomedea ? ? ? ? ? ? ? ? ? ? Pterodroma_feae ? ? ? ? ? ? ? ? ? ? Pterodroma_madeira ? ? ? ? ? ? ? ? ? ? Puffinus_assimilis ? ? ? ? ? ? ? ? ? ? Puffinus_gravis ? ? ? ? ? ? ? ? ? ? Puffinus_griseus ? ? ? ? ? ? ? ? ? ? Puffinus_mauretanicus ? ? ? ? ? ? ? ? ? ? Puffinus_yelkouan ? ? ? ? ? ? ? ? ? ? Lanius_collurio ? ? ? ? ? ? ? ? ? ? Lanius_excubitor ? ? ? ? ? ? ? ? ? ? Lanius_isabellinus ? ? ? ? ? ? ? ? ? ? Lanius_minor ? ? ? ? ? ? ? ? ? ? Lanius_nubicus ? ? ? ? ? ? ? ? ? ? Lanius_senator ? ? ? ? ? ? ? ? ? ? Cyanopica_cyanus ? ? ? ? ? ? ? ? ? ? Nucifraga_caryocatactes ? ? ? ? ? ? ? ? ? ? Perisoreus_infaustus ? ? ? ? ? ? ? ? ? ? Pyrrhocorax_graculus ? ? ? ? ? ? ? ? ? ? Sturnus_roseus ? ? ? ? ? ? ? ? ? ? Sturnus_unicolor ? ? ? ? ? ? ? ? ? ? Bombycilla_garrulus ? ? ? ? ? ? ? ? ? ? Cercotrichas_galactotes ? ? ? ? ? ? ? ? ? ? Ficedula_albicollis ? ? ? ? ? ? ? ? ? ? Ficedula_parva ? ? ? ? ? ? ? ? ? ? Chlidonias_hybrida ? ? ? ? ? ? ? ? ? ? Chlidonias_leucopterus ? ? ? ? ? ? ? ? ? ? Chlidonias_niger ? ? ? ? ? ? ? ? ? ? Sterna_caspia ? ? ? ? ? ? ? ? ? ? Sitta_krueperi ? ? ? ? ? ? ? ? ? ? Sitta_neumayer ? ? ? ? ? ? ? ? ? ? Sitta_whiteheadi ? ? ? ? ? ? ? ? ? ? Certhia_brachydactyla ? ? ? ? ? ? ? ? ? ? Parus_cinctus ? ? ? ? ? ? ? ? ? ? Parus_cyanus ? ? ? ? ? ? ? ? ? ? Parus_lugubris ? ? ? ? ? ? ? ? ? ? Hirundo_daurica ? ? ? ? ? ? ? ? ? ? Hirundo_rupestris ? ? ? ? ? ? ? ? ? ? Pycnonotus_xanthopygos ? ? ? ? ? ? ? ? ? ? Cisticola_juncidis ? ? ? ? ? ? ? ? ? ? Prinia_gracilis ? ? ? ? ? ? ? ? ? ? Luscinia_calliope ? ? ? ? ? ? ? ? ? ? Luscinia_luscinia ? ? ? ? ? ? ? ? ? ? Luscinia_svecica ? ? ? ? ? ? ? ? ? ? Monticola_saxatilis ? ? ? ? ? ? ? ? ? ? Monticola_solitarius ? ? ? ? ? ? ? ? ? ? Oenanthe_deserti ? ? ? ? ? ? ? ? ? ? Oenanthe_finschii ? ? ? ? ? ? ? ? ? ? Oenanthe_hispanica ? ? ? ? ? ? ? ? ? ? Oenanthe_isabellina ? ? ? ? ? ? ? ? ? ? Oenanthe_leucura ? ? ? ? ? ? ? ? ? ? Oenanthe_pleschanka ? ? ? ? ? ? ? ? ? ? Oenanthe_xanthoprymna ? ? ? ? ? ? ? ? ? ? Tarsiger_cyanurus ? ? ? ? ? ? ? ? ? ? Turdus_ruficollis ? ? ? ? ? ? ? ? ? ? Acrocephalus_agricola ? ? ? ? ? ? ? ? ? ? Acrocephalus_arundinaceus ? ? ? ? ? ? ? ? ? ? Acrocephalus_dumetorum ? ? ? ? ? ? ? ? ? ? Acrocephalus_melanopogon ? ? ? ? ? ? ? ? ? ? Acrocephalus_paludicola ? ? ? ? ? ? ? ? ? ? Hippolais_caligata ? ? ? ? ? ? ? ? ? ? Hippolais_icterina ? ? ? ? ? ? ? ? ? ? Hippolais_languida ? ? ? ? ? ? ? ? ? ? Hippolais_olivetorum ? ? ? ? ? ? ? ? ? ? Hippolais_opaca ? ? ? ? ? ? ? ? ? ? Hippolais_pallida ? ? ? ? ? ? ? ? ? ? Hippolais_polyglotta ? ? ? ? ? ? ? ? ? ? Locustella_lanceolata ? ? ? ? ? ? ? ? ? ? Locustella_luscinioides ? ? ? ? ? ? ? ? ? ? Phylloscopus_bonelli ? ? ? ? ? ? ? ? ? ? Phylloscopus_borealis ? ? ? ? ? ? ? ? ? ? Phylloscopus_canariensis ? ? ? ? ? ? ? ? ? ? Phylloscopus_fuscatus ? ? ? ? ? ? ? ? ? ? Phylloscopus_ibericus ? ? ? ? ? ? ? ? ? ? Phylloscopus_inornatus ? ? ? ? ? ? ? ? ? ? Phylloscopus_sindianus ? ? ? ? ? ? ? ? ? ? Phylloscopus_trochiloides ? ? ? ? ? ? ? ? ? ? Sylvia_cantillans ? ? ? ? ? ? ? ? ? ? Sylvia_conspicillata ? ? ? ? ? ? ? ? ? ? Sylvia_hortensis ? ? ? ? ? ? ? ? ? ? Sylvia_melanocephala ? ? ? ? ? ? ? ? ? ? Sylvia_melanothorax ? ? ? ? ? ? ? ? ? ? Sylvia_mystacea ? ? ? ? ? ? ? ? ? ? Sylvia_nana ? ? ? ? ? ? ? ? ? ? Sylvia_nisoria ? ? ? ? ? ? ? ? ? ? Sylvia_rueppelli ? ? ? ? ? ? ? ? ? ? Sylvia_sarda ? ? ? ? ? ? ? ? ? ? Ammomanes_deserti ? ? ? ? ? ? ? ? ? ? Calandrella_brachydactyla ? ? ? ? ? ? ? ? ? ? Calandrella_rufescens ? ? ? ? ? ? ? ? ? ? Chersophilus_duponti ? ? ? ? ? ? ? ? ? ? Eremophila_alpestris ? ? ? ? ? ? ? ? ? ? Galerida_cristata ? ? ? ? ? ? ? ? ? ? Galerida_theklae ? ? ? ? ? ? ? ? ? ? Melanocorypha_bimaculata ? ? ? ? ? ? ? ? ? ? Melanocorypha_calandra ? ? ? ? ? ? ? ? ? ? Melanocorypha_leucoptera ? ? ? ? ? ? ? ? ? ? Melanocorypha_yeltoniensis ? ? ? ? ? ? ? ? ? ? Montifringilla_nivalis ? ? ? ? ? ? ? ? ? ? Passer_hispaniolensis ? ? ? ? ? ? ? ? ? ? Petronia_petronia ? ? ? ? ? ? ? ? ? ? Bucanetes_githagineus ? ? ? ? ? ? ? ? ? ? Carduelis_hornemanni ? ? ? ? ? ? ? ? ? ? Carpodacus_erythrinus ? ? ? ? ? ? ? ? ? ? Carpodacus_rubicilla ? ? ? ? ? ? ? ? ? ? Loxia_leucoptera ? ? ? ? ? ? ? ? ? ? Loxia_pytyopsittacus ? ? ? ? ? ? ? ? ? ? Pinicola_enucleator ? ? ? ? ? ? ? ? ? ? Pyrrhula_murina ? ? ? ? ? ? ? ? ? ? Rhodopechys_mongolicus ? ? ? ? ? ? ? ? ? ? Serinus_canaria ? ? ? ? ? ? ? ? ? ? Serinus_citrinella ? ? ? ? ? ? ? ? ? ? Serinus_pusillus ? ? ? ? ? ? ? ? ? ? Serinus_serinus ? ? ? ? ? ? ? ? ? ? Tichodroma_muraria ? ? ? ? ? ? ? ? ? ? Remiz_pendulinus ? ? ? ? ? ? ? ? ? ? Prunella_atrogularis ? ? ? ? ? ? ? ? ? ? Prunella_collaris ? ? ? ? ? ? ? ? ? ? Prunella_montanella ? ? ? ? ? ? ? ? ? ? Anthus_berthelotii ? ? ? ? ? ? ? ? ? ? Anthus_campestris ? ? ? ? ? ? ? ? ? ? Anthus_cervinus ? ? ? ? ? ? ? ? ? ? Anthus_hodgsoni ? ? ? ? ? ? ? ? ? ? Anthus_spinoletta ? ? ? ? ? ? ? ? ? ? Motacilla_citreola ? ? ? ? ? ? ? ? ? ? Calcarius_lapponicus ? ? ? ? ? ? ? ? ? ? Emberiza_aureola ? ? ? ? ? ? ? ? ? ? Emberiza_bruniceps ? ? ? ? ? ? ? ? ? ? Emberiza_caesia ? ? ? ? ? ? ? ? ? ? Emberiza_cia ? ? ? ? ? ? ? ? ? ? Emberiza_cineracea ? ? ? ? ? ? ? ? ? ? Emberiza_hortulana ? ? ? ? ? ? ? ? ? ? Emberiza_leucocephalos ? ? ? ? ? ? ? ? ? ? Emberiza_melanocephala ? ? ? ? ? ? ? ? ? ? Emberiza_pallasi ? ? ? ? ? ? ? ? ? ? Emberiza_pusilla ? ? ? ? ? ? ? ? ? ? Emberiza_rustica ? ? ? ? ? ? ? ? ? ? ; END; BEGIN TREES; Title Imported_trees; LINK Taxa = Taxa; TRANSLATE 1 Alectoris_barbara, 2 Alectoris_chuckar, 3 Alectoris_graeca, 4 Ammoperdix_griseogularis, 5 Bonasa_Bonasia, 6 Francolinus_francolinus, 7 Tetrao_mlokosiewiczi, 8 Tetraogallus_caspius, 9 Tetraogallus_caucasiucus, 10 Anser_albifrons, 11 Anser_brachyrhynchus, 12 Anser_erythropus, 13 Anser_fabalis, 14 Aythya_marila, 15 Aythya_nyroca, 16 Branta_bernicla, 17 Branta_canadensis, 18 Branta_leucopsis, 19 Branta_ruficollis, 20 Bucephala_islandica, 21 Chen_caerulescens, 22 Clangula_hyemalis, 23 Cygnus_columbianus, 24 Cygnus_cygnus, 25 Histrionicus_histrionicus, 26 Marmaronetta_angustirostris, 27 Melanitta_fusca, 28 Melanitta_perspicillata, 29 Netta_rufina, 30 Oxyura_leucocephala, 31 Polysticta_stelleri, 32 Somateria_spectabilis, 33 Tadorna_ferruginea, 34 Dendrocopos_leucotos, 35 Dendrocopos_medius, 36 Dendrocopos_syriacus, 37 Dryocopus_martius, 38 Jynx_torquilla, 39 Picoides_tridactylus, 40 Picus_canus, 41 Upupa_epops, 42 Coracias_garrulus, 43 Merops_apiaster, 44 Merops_persicus, 45 Ceryle_rudis, 46 Halcyon_smyrnensis, 47 Cuculus_optatus, 48 Apus_affinis, 49 Apus_caffer, 50 Apus_pallidus, 51 Apus_unicolor, 52 Tachymarptis_melba, 53 Aegolius_funereus, 54 Bubo_bubo, 55 Bubo_scandiaca, 56 Glaucidium_passerinum, 57 Ketupa_zeylonensis, 58 Otus_brucei, 59 Otus_scops, 60 Strix_nebulosa, 61 Strix_uralensis, 62 Surnia_ulula, 63 Caprimulgus_ruficollis, 64 Columba_bollii, 65 Columba_junoniae, 66 Columba_trocaz, 67 Stigmatopelia_senegalensis, 68 Chlamydotis_undulata, 69 Otis_tarda, 70 Tetrax_tetrax, 71 Grus_grus, 72 Grus_virgo, 73 Fulica_cristata, 74 Porphyrio_porphyrio, 75 Porzana_parva, 76 Porzana_pusilla, 77 Pterocles_alchata, 78 Pterocles_orientalis, 79 Arenaria_interpres, 80 Calidris_alba, 81 Calidris_bairdii, 82 Calidris_maritima, 83 Calidris_temminckii, 84 Gallinago_media, 85 Limicola_falcinellus, 86 Limosa_lapponica, 87 Lymnocryptes_minimus, 88 Phalaropus_fulicarius, 89 Tringa_erythropus, 90 Tringa_glareola, 91 Tringa_ochropus, 92 Tringa_stagnatilis, 93 Xenus_cinereus, 94 Charadrius_alexandrinus, 95 Charadrius_asiaticus, 96 Charadrius_leschenaultii, 97 Vanellus_indicus, 98 Vanellus_spinosus, 99 Cursorius_cursor, 100 Glareola_nordmanni, 101 Glareola_pratincola, 102 Larus_armenicus, 103 Larus_audouinii, 104 Larus_genei, 105 Larus_glaucoides, 106 Larus_hyperboreus, 107 Larus_ichthyaetus, 108 Larus_minutus, 109 Pagophila_eburnea, 110 Accipiter_badius, 111 Accipiter_brevipes, 112 Aegypius_monachus, 113 Aquila_adalberti, 114 Aquila_clanga, 115 Aquila_heliaca, 116 Aquila_nipalensis, 117 Aquila_pomarina, 118 Buteo_lagopus, 119 Buteo_rufinus, 120 Circaetus_gallicus, 121 Circus_macrourus, 122 Circus_pygargus, 123 Elanus_caeruleus, 124 Gypaetus_barbatus, 125 Gyps_fulvus, 126 Hieraaetus_fasciatus, 127 Hieraaetus_pennatus, 128 Milvus_migrans, 129 Neophron_percnopterus, 130 Alle_alle, 131 Uria_lomvia, 132 Himantopus_himantopus, 133 Falco_biarmicus, 134 Falco_cherrug, 135 Falco_eleonorae, 136 Falco_naumanni, 137 Falco_pelerinoides, 138 Falco_rusticolus, 139 Falco_vespertinus, 140 Podiceps_grisegena, 141 Phaethon_aethereus, 142 Phalacrocorax_pygmeus, 143 Ardea_purpurea, 144 Ardeola_ralloides, 145 Bubulcus_ibis, 146 Egretta_alba, 147 Ixobrychus_minutus, 148 Nycticorax_nycticorax, 149 Phoenicopterus_ruber, 150 Platalea_leucorodia, 151 Plegadis_falcinellus, 152 Pelecanus_crispus, 153 Pelecanus_onocrotalus, 154 Ciconia_ciconia, 155 Ciconia_nigra, 156 Fregata_magnificens, 157 Gavia_immer, 158 Oceanites_oceanicus, 159 Pelagodroma_marina, 160 Bulweria_bulwerii, 161 Calonectris_diomedea, 162 Pterodroma_feae, 163 Pterodroma_madeira, 164 Puffinus_assimilis, 165 Puffinus_gravis, 166 Puffinus_griseus, 167 Puffinus_mauretanicus, 168 Puffinus_yelkouan, 169 Lanius_collurio, 170 Lanius_excubitor, 171 Lanius_isabellinus, 172 Lanius_minor, 173 Lanius_nubicus, 174 Lanius_senator, 175 Cyanopica_cyanus, 176 Nucifraga_caryocatactes, 177 Perisoreus_infaustus, 178 Pyrrhocorax_graculus, 179 Sturnus_roseus, 180 Sturnus_unicolor, 181 Bombycilla_garrulus, 182 Cercotrichas_galactotes, 183 Ficedula_albicollis, 184 Ficedula_parva, 185 Chlidonias_hybrida, 186 Chlidonias_leucopterus, 187 Chlidonias_niger, 188 Sterna_caspia, 189 Sitta_krueperi, 190 Sitta_neumayer, 191 Sitta_whiteheadi, 192 Certhia_brachydactyla, 193 Parus_cinctus, 194 Parus_cyanus, 195 Parus_lugubris, 196 Hirundo_daurica, 197 Hirundo_rupestris, 198 Pycnonotus_xanthopygos, 199 Cisticola_juncidis, 200 Prinia_gracilis, 201 Luscinia_calliope, 202 Luscinia_luscinia, 203 Luscinia_svecica, 204 Monticola_saxatilis, 205 Monticola_solitarius, 206 Oenanthe_deserti, 207 Oenanthe_finschii, 208 Oenanthe_hispanica, 209 Oenanthe_isabellina, 210 Oenanthe_leucura, 211 Oenanthe_pleschanka, 212 Oenanthe_xanthoprymna, 213 Tarsiger_cyanurus, 214 Turdus_ruficollis, 215 Acrocephalus_agricola, 216 Acrocephalus_arundinaceus, 217 Acrocephalus_dumetorum, 218 Acrocephalus_melanopogon, 219 Acrocephalus_paludicola, 220 Hippolais_caligata, 221 Hippolais_icterina, 222 Hippolais_languida, 223 Hippolais_olivetorum, 224 Hippolais_opaca, 225 Hippolais_pallida, 226 Hippolais_polyglotta, 227 Locustella_lanceolata, 228 Locustella_luscinioides, 229 Phylloscopus_bonelli, 230 Phylloscopus_borealis, 231 Phylloscopus_canariensis, 232 Phylloscopus_fuscatus, 233 Phylloscopus_ibericus, 234 Phylloscopus_inornatus, 235 Phylloscopus_sindianus, 236 Phylloscopus_trochiloides, 237 Sylvia_cantillans, 238 Sylvia_conspicillata, 239 Sylvia_hortensis, 240 Sylvia_melanocephala, 241 Sylvia_melanothorax, 242 Sylvia_mystacea, 243 Sylvia_nana, 244 Sylvia_nisoria, 245 Sylvia_rueppelli, 246 Sylvia_sarda, 247 Ammomanes_deserti, 248 Calandrella_brachydactyla, 249 Calandrella_rufescens, 250 Chersophilus_duponti, 251 Eremophila_alpestris, 252 Galerida_cristata, 253 Galerida_theklae, 254 Melanocorypha_bimaculata, 255 Melanocorypha_calandra, 256 Melanocorypha_leucoptera, 257 Melanocorypha_yeltoniensis, 258 Montifringilla_nivalis, 259 Passer_hispaniolensis, 260 Petronia_petronia, 261 Bucanetes_githagineus, 262 Carduelis_hornemanni, 263 Carpodacus_erythrinus, 264 Carpodacus_rubicilla, 265 Loxia_leucoptera, 266 Loxia_pytyopsittacus, 267 Pinicola_enucleator, 268 Pyrrhula_murina, 269 Rhodopechys_mongolicus, 270 Serinus_canaria, 271 Serinus_citrinella, 272 Serinus_pusillus, 273 Serinus_serinus, 274 Tichodroma_muraria, 275 Remiz_pendulinus, 276 Prunella_atrogularis, 277 Prunella_collaris, 278 Prunella_montanella, 279 Anthus_berthelotii, 280 Anthus_campestris, 281 Anthus_cervinus, 282 Anthus_hodgsoni, 283 Anthus_spinoletta, 284 Motacilla_citreola, 285 Calcarius_lapponicus, 286 Emberiza_aureola, 287 Emberiza_bruniceps, 288 Emberiza_caesia, 289 Emberiza_cia, 290 Emberiza_cineracea, 291 Emberiza_hortulana, 292 Emberiza_leucocephalos, 293 Emberiza_melanocephala, 294 Emberiza_pallasi, 295 Emberiza_pusilla, 296 Emberiza_rustica; TREE 'Imported tree 0+' = ((1:5.0,2:5.0,3:5.0):2.0,(4:5.0):2.0,(5:5.0):2.0,(6:5.0):2.0,(7:5.0):2.0,(8:5.0,9:5.0):2.0):22.9,(10:5.0,11:5.0,12:5.0,13:5.0):2.0):5.1,(((34:5.0,35:5.0,36:5.0,37:5.0):2.0,(38:5.0):2.0,(39:5.0):2.0,(40:5.0):2.0):26.3,((41:5.0):2.0):23.4,(((42:5.0):2.0):21.0,((43:5.0,44:5.0):2.0):19.7,((45:5.0):2.0,(46:5.0):2.0):19.7):1.3):2.4):1.6,(((47:5.0):2.0):23.7)),((48:5.0,49:5.0,50:5.0,51:5.0):2.0,(52:5.0):2.0):21.9,((((53:5.0):2.0,(54:5.0,55:5.0):2.0,(56:5.0):2.0,(57:5.0):2.0,(58:5.0,59:5.0):2.0,(60:5.0,61:5.0):2.0,(62:5.0):2.0):19.1,((63:5.0):2.0):19.1):2.8):0.6,((((64:5.0,65:5.0,66:5.0):2.0,(67:5.0):2.0):20.8,(((((68:5.0):2.0,(69:5.0):2.0,(70:5.0):2.0):16.9,((71:5.0,72:5.0):2.0):16.9):2.2,((73:5.0):2.0,(74:5.0):2.0,(75:5.0,76:5.0):2.0):19.1):1.0,((((77:5.0,78:5.0):2.0):17.1,(((79:5.0):2.0,(80:5.0,81:5.0,82:5.0,83:5.0):2.0,(84:5.0):2.0,(85:5.0):2.0,(86:5.0):2.0,(87:5.0):2.0,(88:5.0):2.0,(89:5.0,90:5.0,91:5.0,92:5.0):2.0,(93:5.0):2.0):15.6,(((94:5.0,95:5.0,96:5.0)2,(97:5.0,98:5.0):2.0 ):12.8,(((99):5.0):2.0,(100:5.0,101:5.0):2.0):8.1,((102:5.0,103:5.0,104:5.0,105:5.0,106:5.0,107:5.0,108:5.0):2.0,(109:5.0):2.0):8.1):4.7):2.8):1.5):1.6,((((110:5.0,111:5.0):2.0,(112:5.0):2.0,(113:5.0,114:5.0,115:5.0,116:5.0,117:5.0):2.0,(118:5.0,119:5.0):2.0,(120:5.0):2.0,(121:5.0,122:5.0):2.0,(123:5.0):2.0,(124:5.0):2.0,(125:5.0):2.0,(126:5.0,127:5.0):2.0,(128:5.0):2.0,(129:5.0):2.0):15.2,((130:5.0):2.0,(131:5.0):2.0):15.2,((132:5.0):2.0):15.2,((133:5.0,134:5.0,135:5.0,136:5.0,137:5.0,138:5.0,139:5.0):2.0):15.2):1.2,(((140:5.0):2.0):14.9,(((141:5.0):2.0):14.0,(((142:5.0):2.0):13.3,(((143:5.0):2.0,(144:5.0):2.0,(145:5.0):2.0,(146:5.0):2.0,(147:5.0):2.0,(148:5.0):2.0):12.4,(((149:5.0):2.0):11.5,(((150:5.0):2.0,(151:5.0):2.0):11.1,((((152:5.0,153:5.0):2.0):10.1,((154:5.0,155:5.0):2.0):10.1):0.8,(((156:5.0):2.0):10.7,(((157:5.0):2.0):10.0,((158:5.0):2.0,(159:5.0):2.0):10.0,((160:5.0):2.0,(161:5.0):2.0,(162:5.0):2.0,163:5.0):2.0,(164:5.0,165:5.0,166:5.0,167:5.0,168:5.0):2.0):10. 0):0.7):0.2):0.2):0.4):0.9):0.9):0.7):0.9):1.5):2.3):1.4):0.7):0.8,((((169:5.0,170:5.0,171:5.0,172:5.0,173:5.0,174:5.0):2.0):9.1,((175:5.0):2.0,(176:5.0):2.0,(177:5.0):2.0,(178:5.0):2.0,(179:5.0,180:5.0):2.0):9.1):3.7,((((181:5.0):2.0):10.6,(((182:5.0):2.0,(183:5.0,184:5.0):2.0):9.1,((185:5.0,186:5.0,187:5.0):2.0,(188:5.0):2.0):9.1):1.5):1.1,(((((189:5.0,190:5.0,191:5.0):2.0):10.0,((192:5.0):2.0):10.0):0.8,(((193:5.0,194:5.0,195:5.0):2.0):10.6,(((196:5.0,197:5.0):2.0):10.1,(((198:5.0):2.0):9.5,(((199:5.0):2.0,(200:5.0):2.0):9.4,((201:5.0,202:5.0,203:5.0):2.0,(204:5.0,205:5.0):2.0,(206:5.0,207:5.0,208:5.0,209:5.0,210:5.0,211:5.0,212:5.0):2.0,(213:5.0):2.0,214:7.0):9.4,((215:5.0,216:5.0,217:5.0,218:5.0,219:5.0):2.0,(220:5.0,221:5.0,222:5.0,223:5.0,224:5.0,225:5.0,226:5.0):2.0,(227:5.0,228:5.0):2.0,(229:5.0,230:5.0,231:5.0,232:5.0,233:5.0,234:5.0,235:5.0,236:5.0):2.0,(237:5.0,238:5.0,239:5.0,240:5.0,241:5.0,242:5.0,243:5.0,244:5.0,245:5.0,246:5.0):2.0):9.4):0.1):0.6):0.5):0.2): 0.3,(((247:5.0):2.0,(248:5.0,249:5.0):2.0,(250:5.0):2.0,(251:5.0):2.0,(252:5.0,253:5.0):2.0,(254:5.0,255:5.0,256:5.0,257:5.0):2.0):10.4,(((258:5.0,259:5.0,260:5.0):2.0):10.0,(261:5.0):2.0,(262:5.0):2.0,(263:5.0,264:5.0):2.0,(265:5.0,266:5.0):2.0,(267:5.0):2.0,(268:5.0):2.0,(269:5.0):2.0,(270:5.0,271:5.0,272:5.0,273:5.0):2.0):10.0,((274:5.0):2.0):10.0,((275:5.0):2.0):10.0,((276:5.0,277:5.0,278:5.0):2.0):10.0,((279:5.0,280:5.0,281:5.0,282:5.0,283:5.0):2.0,(284:5.0):2.0):10.0,(285:5.0):2.0,(286:5.0,287:5.0,288:5.0,289:5.0,290:5.0,291:5.0,292:5.0,293:5.0,294:5.0,295:5.0,296:5.0):2.0):10.0):0.4):0.7):0.6):1.1; END; BEGIN ASSUMPTIONS; TYPESET * UNTITLED (CHARACTERS = Categorical) = unord: 1 - 7; TYPESET * UNTITLED (CHARACTERS = Continuous) = Squared: 1 - 10; END; BEGIN CODONS; CODESET * UNTITLED (CHARACTERS = Categorical) = universal: 1 - 7; END; BEGIN MESQUITECHARMODELS; ProbModelSet * UNTITLED (CHARACTERS = Categorical) = 'Mk1 (est.)': 1 - 7; ProbModelSet * UNTITLED (CHARACTERS = Continuous) = Brownian_default: 1 - 10; END; Begin MESQUITE; MESQUITESCRIPTVERSION 2; TITLE AUTO; tell ProjectCoordinator; getEmployee #mesquite.minimal.ManageTaxa.ManageTaxa; tell It; setID 0 7489305339335140846; endTell; getEmployee #mesquite.charMatrices.ManageCharacters.ManageCharacters; tell It; setID 0 3534675600459598498; checksum 0 500806229 null; setID 1 6456195826553758366; checksum 1 1538862558 null; endTell; getWindow; tell It; setResourcesState false false 542; setPopoutState 400; setExplanationSize 0; setAnnotationSize 0; setFontIncAnnot 0; setFontIncExp 0; setSize 1425 800; setLocation 7 22; setFont SanSerif; setFontSize 10; endTell; getEmployee #mesquite.minimal.ManageTaxa.ManageTaxa; tell It; showTaxa #7489305339335140846 #mesquite.lists.TaxonList.TaxonList; tell It; setTaxa #7489305339335140846; getWindow; tell It; newAssistant #mesquite.lists.DefaultTaxaOrder.DefaultTaxaOrder; newAssistant #mesquite.lists.TaxonListCurrPartition.TaxonListCurrPartition; getTable; tell It; rowNamesWidth 146; endTell; setExplanationSize 30; setAnnotationSize 20; setFontIncAnnot 0; setFontIncExp 0; setSize 883 733; setLocation 7 22; setFont SanSerif; setFontSize 10; getToolPalette; tell It; endTell; endTell; showWindow; getEmployee #mesquite.lists.TaxonListAnnotPanel.TaxonListAnnotPanel; tell It; togglePanel off; endTell; endTell; endTell; getEmployee #mesquite.trees.BasicTreeWindowCoord.BasicTreeWindowCoord; tell It; makeTreeWindow #7489305339335140846 #mesquite.trees.BasicTreeWindowMaker.BasicTreeWindowMaker; tell It; suppressEPCResponse; setTreeSource #mesquite.trees.StoredTrees.StoredTrees; tell It; setTreeBlock 1; toggleUseWeights off; endTell; setAssignedID 4022.1227800525891.8782641391695494615; getTreeWindow; tell It; setExplanationSize 30; setAnnotationSize 20; setFontIncAnnot 0; setFontIncExp 0; setSize 883 733; setLocation 7 22; setFont SanSerif; setFontSize 10; getToolPalette; tell It; endTell; setActive; getTreeDrawCoordinator #mesquite.trees.BasicTreeDrawCoordinator.BasicTreeDrawCoordinator; tell It; suppress; setTreeDrawer #mesquite.trees.SquareTree.SquareTree; tell It; setNodeLocs #mesquite.trees.NodeLocsStandard.NodeLocsStandard; tell It; stretchToggle off; branchLengthsToggle off; toggleScale on; toggleBroadScale off; toggleCenter on; toggleEven on; endTell; setEdgeWidth 6; orientUp; toggleCorners off; endTell; setBackground White; setBranchColor Black; showNodeNumbers off; showBranchColors on; labelBranchLengths off; centerBrLenLabels on; showBrLensUnspecified on; showBrLenLabelsOnTerminals on; setBrLenLabelColor 0 0 255; setNumBrLenDecimals 6; desuppress; getEmployee #mesquite.trees.BasicDrawTaxonNames.BasicDrawTaxonNames; tell It; setColor Black; toggleColorPartition on; toggleShadePartition off; toggleNodeLabels on; toggleCenterNodeNames off; toggleShowNames on; namesAngle ?; endTell; endTell; setTreeNumber 1; setTree '(((((((1:5.0,2:5.0,3:5.0):2.0,(4:5.0):2.0,(5:5.0):2.0,(6:5.0):2.0,(7:5.0):2.0,(8:5.0,9:5.0):2.0):22.9,(10:5.0,11:5.0,12:5.0,13:5.0):2.0):5.1,(((34:5.0,35:5.0,36:5.0,37:5.0):2.0,(38:5.0):2.0,(39:5.0):2.0,(40:5.0):2.0):26.3,((41:5.0):2.0):23.4,(((42:5.0):2.0):21.0,((43:5.0,44:5.0):2.0):19.7,((45:5.0):2.0,(46:5.0):2.0):19.7):1.3):2.4):1.6,(((47:5.0):2.0):23.7)),((48:5.0,49:5.0,50:5.0,51:5.0):2.0,(52:5.0):2.0):21.9,((((53:5.0):2.0,(54:5.0,55:5.0):2.0,(56:5.0):2.0,(57:5.0):2.0,(58:5.0,59:5.0):2.0,(60:5.0,61:5.0):2.0,(62:5.0):2.0):19.1,((63:5.0):2.0):19.1):2.8):0.6,((((64:5.0,65:5.0,66:5.0):2.0,(67:5.0):2.0):20.8,(((((68:5.0):2.0,(69:5.0):2.0,(70:5.0):2.0):16.9,((71:5.0,72:5.0):2.0):16.9):2.2,((73:5.0):2.0,(74:5.0):2.0,(75:5.0,76:5.0):2.0):19.1):1.0,((((77:5.0,78:5.0):2.0):17.1,(((79:5.0):2.0,(80:5.0,81:5.0,82:5.0,83:5.0):2.0,(84:5.0):2.0,(85:5.0):2.0,(86:5.0):2.0,(87:5.0):2.0,(88:5.0):2.0,(89:5.0,90:5.0,91:5.0,92:5.0):2.0,(93:5.0):2.0):15.6,(((94:5.0,95:5.0,96:5.0)2, (97:5.0,98:5.0):2.0):12.8,(((99):5.0):2.0,(100:5.0,101:5.0):2.0):8.1,((102:5.0,103:5.0,104:5.0,105:5.0,106:5.0,107:5.0,108:5.0):2.0,(109:5.0):2.0):8.1):4.7):2.8):1.5):1.6,((((110:5.0,111:5.0):2.0,(112:5.0):2.0,(113:5.0,114:5.0,115:5.0,116:5.0,117:5.0):2.0,(118:5.0,119:5.0):2.0,(120:5.0):2.0,(121:5.0,122:5.0):2.0,(123:5.0):2.0,(124:5.0):2.0,(125:5.0):2.0,(126:5.0,127:5.0):2.0,(128:5.0):2.0,(129:5.0):2.0):15.2,((130:5.0):2.0,(131:5.0):2.0):15.2,((132:5.0):2.0):15.2,((133:5.0,134:5.0,135:5.0,136:5.0,137:5.0,138:5.0,139:5.0):2.0):15.2):1.2,(((140:5.0):2.0):14.9,(((141:5.0):2.0):14.0,(((142:5.0):2.0):13.3,(((143:5.0):2.0,(144:5.0):2.0,(145:5.0):2.0,(146:5.0):2.0,(147:5.0):2.0,(148:5.0):2.0):12.4,(((149:5.0):2.0):11.5,(((150:5.0):2.0,(151:5.0):2.0):11.1,((((152:5.0,153:5.0):2.0):10.1,((154:5.0,155:5.0):2.0):10.1):0.8,(((156:5.0):2.0):10.7,(((157:5.0):2.0):10.0,((158:5.0):2.0,(159:5.0):2.0):10.0,((160:5.0):2.0,(161:5.0):2.0,(162:5.0):2.0,163:5.0):2.0,(164:5.0,165:5.0,166:5.0,167:5. 0,168:5.0):2.0):10.0):0.7):0.2):0.2):0.4):0.9):0.9):0.7):0.9):1.5):2.3):1.4):0.7):0.8,((((169:5.0,170:5.0,171:5.0,172:5.0,173:5.0,174:5.0):2.0):9.1,((175:5.0):2.0,(176:5.0):2.0,(177:5.0):2.0,(178:5.0):2.0,(179:5.0,180:5.0):2.0):9.1):3.7,((((181:5.0):2.0):10.6,(((182:5.0):2.0,(183:5.0,184:5.0):2.0):9.1,((185:5.0,186:5.0,187:5.0):2.0,(188:5.0):2.0):9.1):1.5):1.1,(((((189:5.0,190:5.0,191:5.0):2.0):10.0,((192:5.0):2.0):10.0):0.8,(((193:5.0,194:5.0,195:5.0):2.0):10.6,(((196:5.0,197:5.0):2.0):10.1,(((198:5.0):2.0):9.5,(((199:5.0):2.0,(200:5.0):2.0):9.4,((201:5.0,202:5.0,203:5.0):2.0,(204:5.0,205:5.0):2.0,(206:5.0,207:5.0,208:5.0,209:5.0,210:5.0,211:5.0,212:5.0):2.0,(213:5.0):2.0,214:7.0):9.4,((215:5.0,216:5.0,217:5.0,218:5.0,219:5.0):2.0,(220:5.0,221:5.0,222:5.0,223:5.0,224:5.0,225:5.0,226:5.0):2.0,(227:5.0,228:5.0):2.0,(229:5.0,230:5.0,231:5.0,232:5.0,233:5.0,234:5.0,235:5.0,236:5.0):2.0,(237:5.0,238:5.0,239:5.0,240:5.0,241:5.0,242:5.0,243:5.0,244:5.0,245:5.0,246:5.0):2.0):9.4):0 .1):0.6):0.5):0.2):0.3,(((247:5.0):2.0,(248:5.0,249:5.0):2.0,(250:5.0):2.0,(251:5.0):2.0,(252:5.0,253:5.0):2.0,(254:5.0,255:5.0,256:5.0,257:5.0):2.0):10.4,(((258:5.0,259:5.0,260:5.0):2.0):10.0,(261:5.0):2.0,(262:5.0):2.0,(263:5.0,264:5.0):2.0,(265:5.0,266:5.0):2.0,(267:5.0):2.0,(268:5.0):2.0,(269:5.0):2.0,(270:5.0,271:5.0,272:5.0,273:5.0):2.0):10.0,((274:5.0):2.0):10.0,((275:5.0):2.0):10.0,((276:5.0,277:5.0,278:5.0):2.0):10.0,((279:5.0,280:5.0,281:5.0,282:5.0,283:5.0):2.0,(284:5.0):2.0):10.0,(285:5.0):2.0,(286:5.0,287:5.0,288:5.0,289:5.0,290:5.0,291:5.0,292:5.0,293:5.0,294:5.0,295:5.0,296:5.0):2.0):10.0):0.4):0.7):0.6):1.1;'; useSuggestedSize on; toggleTextOnTree off; showWindow; endTell; desuppressEPCResponse; getEmployee #mesquite.trees.ColorBranches.ColorBranches; tell It; setColor Red; removeColor off; endTell; getEmployee #mesquite.ornamental.BranchNotes.BranchNotes; tell It; setAlwaysOn off; endTell; getEmployee #mesquite.ornamental.ColorTreeByPartition.ColorTreeByPartition; tell It; colorByPartition off; endTell; getEmployee #mesquite.ornamental.DrawTreeAssocDoubles.DrawTreeAssocDoubles; tell It; setOn on; setDigits 4; writeAsPercentage off; toggleCentred on; toggleHorizontal on; setFontSize 10; setOffset 0 0; endTell; getEmployee #mesquite.trees.TreeInfoValues.TreeInfoValues; tell It; panelOpen false; endTell; endTell; endTell; getEmployee #mesquite.charMatrices.BasicDataWindowCoord.BasicDataWindowCoord; tell It; showDataWindow #3534675600459598498 #mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindowMaker; tell It; getWindow; tell It; setExplanationSize 30; setAnnotationSize 20; setFontIncAnnot 0; setFontIncExp 0; setSize 883 733; setLocation 7 22; setFont SanSerif; setFontSize 10; getToolPalette; tell It; endTell; setTool mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindow.arrow; colorCells #mesquite.charMatrices.NoColor.NoColor; colorRowNames #mesquite.charMatrices.TaxonGroupColor.TaxonGroupColor; colorColumnNames #mesquite.charMatrices.CharGroupColor.CharGroupColor; colorText #mesquite.charMatrices.NoColor.NoColor; setBackground White; toggleShowNames on; toggleShowTaxonNames on; toggleTight off; toggleShowChanges on; toggleSeparateLines off; toggleShowStates on; toggleAutoWCharNames on; toggleShowDefaultCharNames off; toggleConstrainCW on; toggleBirdsEye off; toggleAllowAutosize on; toggleColorsPanel off; toggleDiagonal on; setDiagonalHeight 80; toggleLinkedScrolling on; toggleScrollLinkedTables off; endTell; showWindow; getWindow; tell It; forceAutosize; endTell; getEmployee #mesquite.charMatrices.ColorCells.ColorCells; tell It; setColor Red; removeColor off; endTell; getEmployee #mesquite.categ.StateNamesStrip.StateNamesStrip; tell It; showStrip off; endTell; getEmployee #mesquite.charMatrices.AnnotPanel.AnnotPanel; tell It; togglePanel off; endTell; getEmployee #mesquite.charMatrices.CharReferenceStrip.CharReferenceStrip; tell It; showStrip off; endTell; getEmployee #mesquite.charMatrices.QuickKeySelector.QuickKeySelector; tell It; autotabOff; endTell; getEmployee #mesquite.categ.SmallStateNamesEditor.SmallStateNamesEditor; tell It; panelOpen true; endTell; endTell; showDataWindow #6456195826553758366 #mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindowMaker; tell It; getWindow; tell It; setExplanationSize 30; setAnnotationSize 20; setFontIncAnnot 0; setFontIncExp 0; setSize 883 733; setLocation 7 22; setFont SanSerif; setFontSize 10; getToolPalette; tell It; endTell; setTool mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindow.arrow; colorCells #mesquite.charMatrices.NoColor.NoColor; colorRowNames #mesquite.charMatrices.TaxonGroupColor.TaxonGroupColor; colorColumnNames #mesquite.charMatrices.CharGroupColor.CharGroupColor; colorText #mesquite.charMatrices.NoColor.NoColor; setBackground White; toggleShowNames on; toggleShowTaxonNames on; toggleTight off; toggleShowChanges on; toggleSeparateLines off; toggleShowStates on; toggleAutoWCharNames on; toggleShowDefaultCharNames off; toggleConstrainCW on; toggleBirdsEye off; toggleAllowAutosize on; toggleColorsPanel off; toggleLinkedScrolling on; toggleScrollLinkedTables off; endTell; showWindow; getWindow; tell It; forceAutosize; endTell; getEmployee #mesquite.charMatrices.ColorCells.ColorCells; tell It; setColor Red; removeColor off; endTell; getEmployee #mesquite.charMatrices.AnnotPanel.AnnotPanel; tell It; togglePanel off; endTell; getEmployee #mesquite.charMatrices.CharReferenceStrip.CharReferenceStrip; tell It; showStrip off; endTell; getEmployee #mesquite.cont.ItemsEditorForInfoPanel.ItemsEditorForInfoPanel; tell It; panelOpen false; endTell; endTell; endTell; endTell; end; From cowan.pd at gmail.com Fri Nov 28 22:32:22 2008 From: cowan.pd at gmail.com (Peter Cowan) Date: Fri, 28 Nov 2008 13:32:22 -0800 Subject: [Rd] Unable to plot or analyse phylogeny (PR#13345) In-Reply-To: <20081128145510.75BE0282EFF6@mail.pubhealth.ku.dk> References: <20081128145510.75BE0282EFF6@mail.pubhealth.ku.dk> Message-ID: Emily, I think you've directed your email to the wrong list. The R-bugs list is solely for bugs regarding the R core, not add-on packages, like you are using. R-devel, is primarily targeted at people who write such add-on packages, and also inappropriate for your question. Keep in mind that there are well over 1000 add-on packages and the core developers cannot (and likely do not want to) be familiar with all of them. Please see: This question should be directed to r-help or even better the r-sig-phylo list which you can subscribe to here. http://www.r-project.org/mail.html I also notice that you don't mention what packages you have loaded and what versions those are, the posting guide link provides suggestions for how to find that information. Peter On Fri, Nov 28, 2008 at 6:55 AM, wrote: > Full_Name: Emily Green > Version: 2.8.0 GUI 1.26 > OS: MacBrook Pro with 2.5 GHz processor, using Mac OS X 10.5.5 > Submission from: (NULL) (144.32.69.137) > > > I am wanting to correct for phylogeny using a phylogenetic tree of 296 birds > species, which I have constructed myself. The file format is correct and I have > checked its display in Mesquite, which exported the nexus file (I've pasted the > text of the file at the end of this message, the matrices are purposefully > blank). As a text file this looks absolutely fine to me. R can at least read the > tree fine using read.tree to produce the following: >> sa<-read.nexus("sa_r.txt.nex") >> summary(sa) > Phylogenetic tree: sa > > Number of tips: 296 > Number of nodes: 239 > Branch lengths: > mean: NA > variance: NA > distribution summary: > Min. 1st Qu. Median 3rd Qu. Max. NA's > 8.00e-202 8.00e-202 2.00e+00 5.00e+00 2.63e+01 3.00e+00 > Root edge: 1.1 > First ten tip labels: Alectoris_barbara > Alectoris_chuckar > Alectoris_graeca > Ammoperdix_griseogularis > Bonasa_Bonasia > Francolinus_francolinus > Tetrao_mlokosiewiczi > Tetraogallus_caspius > Tetraogallus_caucasiucus > Anser_albifrons > First ten node labels: 0 > 0 > 0 > 0 > 0 > 0 > 0 > 0 > 0 > 0 > > I was a bit worried as to why no mean or variance of branch length was produced, > when these are all present in the nexus file and Mesquite can recognise them. > But I proceeded to attempt to plot the tree in R to check it displayed correctly > here. This is something I've done before in R with smaller trees and it worked > fine. But with this tree it produced the following error: >> plot.phylo(sa) > Error: cannot allocate vector of size 1.4 Gb > R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > > The same problem comes up when I try to run an autocorrelative model with some > dummy continuous data. (I've tried many different functions, all produce similar > error responses): >> Moran.I(dummy$dist, cophenetic(sa)) > Error: cannot allocate vector of size 1.4 Gb > R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > R(539,0xa0810fa0) malloc: *** mmap(size=1488809984) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > > I fear my tree may be too big to handle, but this is my dataset and I wanted to > make use of the range and power of R's analytical capabilites over other > programs like Mesquite. > If you can solve my problem I'd be very very grateful. > Cheers, > Emily > > > PS - the text of the nexus file > #NEXUS > [written Thu Nov 27 17:49:33 GMT 2008 by Mesquite version 2.5 (build j77) at > sns69-198.york.ac.uk/144.32.69.198] > > BEGIN TAXA; > TITLE Taxa; > DIMENSIONS NTAX=296; > TAXLABELS > Alectoris_barbara Alectoris_chuckar Alectoris_graeca Ammoperdix_griseogularis > Bonasa_Bonasia Francolinus_francolinus Tetrao_mlokosiewiczi Tetraogallus_caspius > Tetraogallus_caucasiucus Anser_albifrons Anser_brachyrhynchus Anser_erythropus > Anser_fabalis Aythya_marila Aythya_nyroca Branta_bernicla Branta_canadensis > Branta_leucopsis Branta_ruficollis Bucephala_islandica Chen_caerulescens > Clangula_hyemalis Cygnus_columbianus Cygnus_cygnus Histrionicus_histrionicus > Marmaronetta_angustirostris Melanitta_fusca Melanitta_perspicillata Netta_rufina > Oxyura_leucocephala Polysticta_stelleri Somateria_spectabilis Tadorna_ferruginea > Dendrocopos_leucotos Dendrocopos_medius Dendrocopos_syriacus Dryocopus_martius > Jynx_torquilla Picoides_tridactylus Picus_canus Upupa_epops Coracias_garrulus > Merops_apiaster Merops_persicus Ceryle_rudis Halcyon_smyrnensis Cuculus_optatus > Apus_affinis Apus_caffer Apus_pallidus Apus_unicolor Tachymarptis_melba > Aegolius_funereus Bubo_bubo Bubo_scandiaca Glaucidium_passerinum > Ketupa_zeylonensis Otus_brucei Otus_scops Strix_nebulosa Strix_uralensis > Surnia_ulula Caprimulgus_ruficollis Columba_bollii Columba_junoniae > Columba_trocaz Stigmatopelia_senegalensis Chlamydotis_undulata Otis_tarda > Tetrax_tetrax Grus_grus Grus_virgo Fulica_cristata Porphyrio_porphyrio > Porzana_parva Porzana_pusilla Pterocles_alchata Pterocles_orientalis > Arenaria_interpres Calidris_alba Calidris_bairdii Calidris_maritima > Calidris_temminckii Gallinago_media Limicola_falcinellus Limosa_lapponica > Lymnocryptes_minimus Phalaropus_fulicarius Tringa_erythropus Tringa_glareola > Tringa_ochropus Tringa_stagnatilis Xenus_cinereus Charadrius_alexandrinus > Charadrius_asiaticus Charadrius_leschenaultii Vanellus_indicus Vanellus_spinosus > Cursorius_cursor Glareola_nordmanni Glareola_pratincola Larus_armenicus > Larus_audouinii Larus_genei Larus_glaucoides Larus_hyperboreus Larus_ichthyaetus > Larus_minutus Pagophila_eburnea Accipiter_badius Accipiter_brevipes > Aegypius_monachus Aquila_adalberti Aquila_clanga Aquila_heliaca > Aquila_nipalensis Aquila_pomarina Buteo_lagopus Buteo_rufinus Circaetus_gallicus > Circus_macrourus Circus_pygargus Elanus_caeruleus Gypaetus_barbatus Gyps_fulvus > Hieraaetus_fasciatus Hieraaetus_pennatus Milvus_migrans Neophron_percnopterus > Alle_alle Uria_lomvia Himantopus_himantopus Falco_biarmicus Falco_cherrug > Falco_eleonorae Falco_naumanni Falco_pelerinoides Falco_rusticolus > Falco_vespertinus Podiceps_grisegena Phaethon_aethereus Phalacrocorax_pygmeus > Ardea_purpurea Ardeola_ralloides Bubulcus_ibis Egretta_alba Ixobrychus_minutus > Nycticorax_nycticorax Phoenicopterus_ruber Platalea_leucorodia > Plegadis_falcinellus Pelecanus_crispus Pelecanus_onocrotalus Ciconia_ciconia > Ciconia_nigra Fregata_magnificens Gavia_immer Oceanites_oceanicus > Pelagodroma_marina Bulweria_bulwerii Calonectris_diomedea Pterodroma_feae > Pterodroma_madeira Puffinus_assimilis Puffinus_gravis Puffinus_griseus > Puffinus_mauretanicus Puffinus_yelkouan Lanius_collurio Lanius_excubitor > Lanius_isabellinus Lanius_minor Lanius_nubicus Lanius_senator Cyanopica_cyanus > Nucifraga_caryocatactes Perisoreus_infaustus Pyrrhocorax_graculus Sturnus_roseus > Sturnus_unicolor Bombycilla_garrulus Cercotrichas_galactotes Ficedula_albicollis > Ficedula_parva Chlidonias_hybrida Chlidonias_leucopterus Chlidonias_niger > Sterna_caspia Sitta_krueperi Sitta_neumayer Sitta_whiteheadi > Certhia_brachydactyla Parus_cinctus Parus_cyanus Parus_lugubris Hirundo_daurica > Hirundo_rupestris Pycnonotus_xanthopygos Cisticola_juncidis Prinia_gracilis > Luscinia_calliope Luscinia_luscinia Luscinia_svecica Monticola_saxatilis > Monticola_solitarius Oenanthe_deserti Oenanthe_finschii Oenanthe_hispanica > Oenanthe_isabellina Oenanthe_leucura Oenanthe_pleschanka Oenanthe_xanthoprymna > Tarsiger_cyanurus Turdus_ruficollis Acrocephalus_agricola > Acrocephalus_arundinaceus Acrocephalus_dumetorum Acrocephalus_melanopogon > Acrocephalus_paludicola Hippolais_caligata Hippolais_icterina Hippolais_languida > Hippolais_olivetorum Hippolais_opaca Hippolais_pallida Hippolais_polyglotta > Locustella_lanceolata Locustella_luscinioides Phylloscopus_bonelli > Phylloscopus_borealis Phylloscopus_canariensis Phylloscopus_fuscatus > Phylloscopus_ibericus Phylloscopus_inornatus Phylloscopus_sindianus > Phylloscopus_trochiloides Sylvia_cantillans Sylvia_conspicillata > Sylvia_hortensis Sylvia_melanocephala Sylvia_melanothorax Sylvia_mystacea > Sylvia_nana Sylvia_nisoria Sylvia_rueppelli Sylvia_sarda Ammomanes_deserti > Calandrella_brachydactyla Calandrella_rufescens Chersophilus_duponti > Eremophila_alpestris Galerida_cristata Galerida_theklae Melanocorypha_bimaculata > Melanocorypha_calandra Melanocorypha_leucoptera Melanocorypha_yeltoniensis > Montifringilla_nivalis Passer_hispaniolensis Petronia_petronia > Bucanetes_githagineus Carduelis_hornemanni Carpodacus_erythrinus > Carpodacus_rubicilla Loxia_leucoptera Loxia_pytyopsittacus Pinicola_enucleator > Pyrrhula_murina Rhodopechys_mongolicus Serinus_canaria Serinus_citrinella > Serinus_pusillus Serinus_serinus Tichodroma_muraria Remiz_pendulinus > Prunella_atrogularis Prunella_collaris Prunella_montanella Anthus_berthelotii > Anthus_campestris Anthus_cervinus Anthus_hodgsoni Anthus_spinoletta > Motacilla_citreola Calcarius_lapponicus Emberiza_aureola Emberiza_bruniceps > Emberiza_caesia Emberiza_cia Emberiza_cineracea Emberiza_hortulana > Emberiza_leucocephalos Emberiza_melanocephala Emberiza_pallasi Emberiza_pusilla > Emberiza_rustica > ; > > END; > > > BEGIN CHARACTERS; > TITLE Categorical; > DIMENSIONS NCHAR=7; > FORMAT DATATYPE = STANDARD GAP = - MISSING = ? SYMBOLS = " 0 1"; > MATRIX > Alectoris_barbara ??????? > Alectoris_chuckar ??????? > Alectoris_graeca ??????? > Ammoperdix_griseogularis ??????? > Bonasa_Bonasia ??????? > Francolinus_francolinus ??????? > Tetrao_mlokosiewiczi ??????? > Tetraogallus_caspius ??????? > Tetraogallus_caucasiucus ??????? > Anser_albifrons ??????? > Anser_brachyrhynchus ??????? > Anser_erythropus ??????? > Anser_fabalis ??????? > Aythya_marila ??????? > Aythya_nyroca ??????? > Branta_bernicla ??????? > Branta_canadensis ??????? > Branta_leucopsis ??????? > Branta_ruficollis ??????? > Bucephala_islandica ??????? > Chen_caerulescens ??????? > Clangula_hyemalis ??????? > Cygnus_columbianus ??????? > Cygnus_cygnus ??????? > Histrionicus_histrionicus ??????? > Marmaronetta_angustirostris ??????? > Melanitta_fusca ??????? > Melanitta_perspicillata ??????? > Netta_rufina ??????? > Oxyura_leucocephala ??????? > Polysticta_stelleri ??????? > Somateria_spectabilis ??????? > Tadorna_ferruginea ??????? > Dendrocopos_leucotos ??????? > Dendrocopos_medius ??????? > Dendrocopos_syriacus ??????? > Dryocopus_martius ??????? > Jynx_torquilla ??????? > Picoides_tridactylus ??????? > Picus_canus ??????? > Upupa_epops ??????? > Coracias_garrulus ??????? > Merops_apiaster ??????? > Merops_persicus ??????? > Ceryle_rudis ??????? > Halcyon_smyrnensis ??????? > Cuculus_optatus ??????? > Apus_affinis ??????? > Apus_caffer ??????? > Apus_pallidus ??????? > Apus_unicolor ??????? > Tachymarptis_melba ??????? > Aegolius_funereus ??????? > Bubo_bubo ??????? > Bubo_scandiaca ??????? > Glaucidium_passerinum ??????? > Ketupa_zeylonensis ??????? > Otus_brucei ??????? > Otus_scops ??????? > Strix_nebulosa ??????? > Strix_uralensis ??????? > Surnia_ulula ??????? > Caprimulgus_ruficollis ??????? > Columba_bollii ??????? > Columba_junoniae ??????? > Columba_trocaz ??????? > Stigmatopelia_senegalensis ??????? > Chlamydotis_undulata ??????? > Otis_tarda ??????? > Tetrax_tetrax ??????? > Grus_grus ??????? > Grus_virgo ??????? > Fulica_cristata ??????? > Porphyrio_porphyrio ??????? > Porzana_parva ??????? > Porzana_pusilla ??????? > Pterocles_alchata ??????? > Pterocles_orientalis ??????? > Arenaria_interpres ??????? > Calidris_alba ??????? > Calidris_bairdii ??????? > Calidris_maritima ??????? > Calidris_temminckii ??????? > Gallinago_media ??????? > Limicola_falcinellus ??????? > Limosa_lapponica ??????? > Lymnocryptes_minimus ??????? > Phalaropus_fulicarius ??????? > Tringa_erythropus ??????? > Tringa_glareola ??????? > Tringa_ochropus ??????? > Tringa_stagnatilis ??????? > Xenus_cinereus ??????? > Charadrius_alexandrinus ??????? > Charadrius_asiaticus ??????? > Charadrius_leschenaultii ??????? > Vanellus_indicus ??????? > Vanellus_spinosus ??????? > Cursorius_cursor ??????? > Glareola_nordmanni ??????? > Glareola_pratincola ??????? > Larus_armenicus ??????? > Larus_audouinii ??????? > Larus_genei ??????? > Larus_glaucoides ??????? > Larus_hyperboreus ??????? > Larus_ichthyaetus ??????? > Larus_minutus ??????? > Pagophila_eburnea ??????? > Accipiter_badius ??????? > Accipiter_brevipes ??????? > Aegypius_monachus ??????? > Aquila_adalberti ??????? > Aquila_clanga ??????? > Aquila_heliaca ??????? > Aquila_nipalensis ??????? > Aquila_pomarina ??????? > Buteo_lagopus ??????? > Buteo_rufinus ??????? > Circaetus_gallicus ??????? > Circus_macrourus ??????? > Circus_pygargus ??????? > Elanus_caeruleus ??????? > Gypaetus_barbatus ??????? > Gyps_fulvus ??????? > Hieraaetus_fasciatus ??????? > Hieraaetus_pennatus ??????? > Milvus_migrans ??????? > Neophron_percnopterus ??????? > Alle_alle ??????? > Uria_lomvia ??????? > Himantopus_himantopus ??????? > Falco_biarmicus ??????? > Falco_cherrug ??????? > Falco_eleonorae ??????? > Falco_naumanni ??????? > Falco_pelerinoides ??????? > Falco_rusticolus ??????? > Falco_vespertinus ??????? > Podiceps_grisegena ??????? > Phaethon_aethereus ??????? > Phalacrocorax_pygmeus ??????? > Ardea_purpurea ??????? > Ardeola_ralloides ??????? > Bubulcus_ibis ??????? > Egretta_alba ??????? > Ixobrychus_minutus ??????? > Nycticorax_nycticorax ??????? > Phoenicopterus_ruber ??????? > Platalea_leucorodia ??????? > Plegadis_falcinellus ??????? > Pelecanus_crispus ??????? > Pelecanus_onocrotalus ??????? > Ciconia_ciconia ??????? > Ciconia_nigra ??????? > Fregata_magnificens ??????? > Gavia_immer ??????? > Oceanites_oceanicus ??????? > Pelagodroma_marina ??????? > Bulweria_bulwerii ??????? > Calonectris_diomedea ??????? > Pterodroma_feae ??????? > Pterodroma_madeira ??????? > Puffinus_assimilis ??????? > Puffinus_gravis ??????? > Puffinus_griseus ??????? > Puffinus_mauretanicus ??????? > Puffinus_yelkouan ??????? > Lanius_collurio ??????? > Lanius_excubitor ??????? > Lanius_isabellinus ??????? > Lanius_minor ??????? > Lanius_nubicus ??????? > Lanius_senator ??????? > Cyanopica_cyanus ??????? > Nucifraga_caryocatactes ??????? > Perisoreus_infaustus ??????? > Pyrrhocorax_graculus ??????? > Sturnus_roseus ??????? > Sturnus_unicolor ??????? > Bombycilla_garrulus ??????? > Cercotrichas_galactotes ??????? > Ficedula_albicollis ??????? > Ficedula_parva ??????? > Chlidonias_hybrida ??????? > Chlidonias_leucopterus ??????? > Chlidonias_niger ??????? > Sterna_caspia ??????? > Sitta_krueperi ??????? > Sitta_neumayer ??????? > Sitta_whiteheadi ??????? > Certhia_brachydactyla ??????? > Parus_cinctus ??????? > Parus_cyanus ??????? > Parus_lugubris ??????? > Hirundo_daurica ??????? > Hirundo_rupestris ??????? > Pycnonotus_xanthopygos ??????? > Cisticola_juncidis ??????? > Prinia_gracilis ??????? > Luscinia_calliope ??????? > Luscinia_luscinia ??????? > Luscinia_svecica ??????? > Monticola_saxatilis ??????? > Monticola_solitarius ??????? > Oenanthe_deserti ??????? > Oenanthe_finschii ??????? > Oenanthe_hispanica ??????? > Oenanthe_isabellina ??????? > Oenanthe_leucura ??????? > Oenanthe_pleschanka ??????? > Oenanthe_xanthoprymna ??????? > Tarsiger_cyanurus ??????? > Turdus_ruficollis ??????? > Acrocephalus_agricola ??????? > Acrocephalus_arundinaceus ??????? > Acrocephalus_dumetorum ??????? > Acrocephalus_melanopogon ??????? > Acrocephalus_paludicola ??????? > Hippolais_caligata ??????? > Hippolais_icterina ??????? > Hippolais_languida ??????? > Hippolais_olivetorum ??????? > Hippolais_opaca ??????? > Hippolais_pallida ??????? > Hippolais_polyglotta ??????? > Locustella_lanceolata ??????? > Locustella_luscinioides ??????? > Phylloscopus_bonelli ??????? > Phylloscopus_borealis ??????? > Phylloscopus_canariensis ??????? > Phylloscopus_fuscatus ??????? > Phylloscopus_ibericus ??????? > Phylloscopus_inornatus ??????? > Phylloscopus_sindianus ??????? > Phylloscopus_trochiloides ??????? > Sylvia_cantillans ??????? > Sylvia_conspicillata ??????? > Sylvia_hortensis ??????? > Sylvia_melanocephala ??????? > Sylvia_melanothorax ??????? > Sylvia_mystacea ??????? > Sylvia_nana ??????? > Sylvia_nisoria ??????? > Sylvia_rueppelli ??????? > Sylvia_sarda ??????? > Ammomanes_deserti ??????? > Calandrella_brachydactyla ??????? > Calandrella_rufescens ??????? > Chersophilus_duponti ??????? > Eremophila_alpestris ??????? > Galerida_cristata ??????? > Galerida_theklae ??????? > Melanocorypha_bimaculata ??????? > Melanocorypha_calandra ??????? > Melanocorypha_leucoptera ??????? > Melanocorypha_yeltoniensis ??????? > Montifringilla_nivalis ??????? > Passer_hispaniolensis ??????? > Petronia_petronia ??????? > Bucanetes_githagineus ??????? > Carduelis_hornemanni ??????? > Carpodacus_erythrinus ??????? > Carpodacus_rubicilla ??????? > Loxia_leucoptera ??????? > Loxia_pytyopsittacus ??????? > Pinicola_enucleator ??????? > Pyrrhula_murina ??????? > Rhodopechys_mongolicus ??????? > Serinus_canaria ??????? > Serinus_citrinella ??????? > Serinus_pusillus ??????? > Serinus_serinus ??????? > Tichodroma_muraria ??????? > Remiz_pendulinus ??????? > Prunella_atrogularis ??????? > Prunella_collaris ??????? > Prunella_montanella ??????? > Anthus_berthelotii ??????? > Anthus_campestris ??????? > Anthus_cervinus ??????? > Anthus_hodgsoni ??????? > Anthus_spinoletta ??????? > Motacilla_citreola ??????? > Calcarius_lapponicus ??????? > Emberiza_aureola ??????? > Emberiza_bruniceps ??????? > Emberiza_caesia ??????? > Emberiza_cia ??????? > Emberiza_cineracea ??????? > Emberiza_hortulana ??????? > Emberiza_leucocephalos ??????? > Emberiza_melanocephala ??????? > Emberiza_pallasi ??????? > Emberiza_pusilla ??????? > Emberiza_rustica ??????? > > ; > > END; > BEGIN CHARACTERS; > TITLE Continuous; > DIMENSIONS NCHAR=10; > FORMAT DATATYPE = CONTINUOUS GAP = - MISSING = ?; > MATRIX > Alectoris_barbara ? ? ? ? ? ? ? ? ? ? > Alectoris_chuckar ? ? ? ? ? ? ? ? ? ? > Alectoris_graeca ? ? ? ? ? ? ? ? ? ? > Ammoperdix_griseogularis ? ? ? ? ? ? ? ? ? ? > Bonasa_Bonasia ? ? ? ? ? ? ? ? ? ? > Francolinus_francolinus ? ? ? ? ? ? ? ? ? ? > Tetrao_mlokosiewiczi ? ? ? ? ? ? ? ? ? ? > Tetraogallus_caspius ? ? ? ? ? ? ? ? ? ? > Tetraogallus_caucasiucus ? ? ? ? ? ? ? ? ? ? > Anser_albifrons ? ? ? ? ? ? ? ? ? ? > Anser_brachyrhynchus ? ? ? ? ? ? ? ? ? ? > Anser_erythropus ? ? ? ? ? ? ? ? ? ? > Anser_fabalis ? ? ? ? ? ? ? ? ? ? > Aythya_marila ? ? ? ? ? ? ? ? ? ? > Aythya_nyroca ? ? ? ? ? ? ? ? ? ? > Branta_bernicla ? ? ? ? ? ? ? ? ? ? > Branta_canadensis ? ? ? ? ? ? ? ? ? ? > Branta_leucopsis ? ? ? ? ? ? ? ? ? ? > Branta_ruficollis ? ? ? ? ? ? ? ? ? ? > Bucephala_islandica ? ? ? ? ? ? ? ? ? ? > Chen_caerulescens ? ? ? ? ? ? ? ? ? ? > Clangula_hyemalis ? ? ? ? ? ? ? ? ? ? > Cygnus_columbianus ? ? ? ? ? ? ? ? ? ? > Cygnus_cygnus ? ? ? ? ? ? ? ? ? ? > Histrionicus_histrionicus ? ? ? ? ? ? ? ? ? ? > Marmaronetta_angustirostris ? ? ? ? ? ? ? ? ? ? > Melanitta_fusca ? ? ? ? ? ? ? ? ? ? > Melanitta_perspicillata ? ? ? ? ? ? ? ? ? ? > Netta_rufina ? ? ? ? ? ? ? ? ? ? > Oxyura_leucocephala ? ? ? ? ? ? ? ? ? ? > Polysticta_stelleri ? ? ? ? ? ? ? ? ? ? > Somateria_spectabilis ? ? ? ? ? ? ? ? ? ? > Tadorna_ferruginea ? ? ? ? ? ? ? ? ? ? > Dendrocopos_leucotos ? ? ? ? ? ? ? ? ? ? > Dendrocopos_medius ? ? ? ? ? ? ? ? ? ? > Dendrocopos_syriacus ? ? ? ? ? ? ? ? ? ? > Dryocopus_martius ? ? ? ? ? ? ? ? ? ? > Jynx_torquilla ? ? ? ? ? ? ? ? ? ? > Picoides_tridactylus ? ? ? ? ? ? ? ? ? ? > Picus_canus ? ? ? ? ? ? ? ? ? ? > Upupa_epops ? ? ? ? ? ? ? ? ? ? > Coracias_garrulus ? ? ? ? ? ? ? ? ? ? > Merops_apiaster ? ? ? ? ? ? ? ? ? ? > Merops_persicus ? ? ? ? ? ? ? ? ? ? > Ceryle_rudis ? ? ? ? ? ? ? ? ? ? > Halcyon_smyrnensis ? ? ? ? ? ? ? ? ? ? > Cuculus_optatus ? ? ? ? ? ? ? ? ? ? > Apus_affinis ? ? ? ? ? ? ? ? ? ? > Apus_caffer ? ? ? ? ? ? ? ? ? ? > Apus_pallidus ? ? ? ? ? ? ? ? ? ? > Apus_unicolor ? ? ? ? ? ? ? ? ? ? > Tachymarptis_melba ? ? ? ? ? ? ? ? ? ? > Aegolius_funereus ? ? ? ? ? ? ? ? ? ? > Bubo_bubo ? ? ? ? ? ? ? ? ? ? > Bubo_scandiaca ? ? ? ? ? ? ? ? ? ? > Glaucidium_passerinum ? ? ? ? ? ? ? ? ? ? > Ketupa_zeylonensis ? ? ? ? ? ? ? ? ? ? > Otus_brucei ? ? ? ? ? ? ? ? ? ? > Otus_scops ? ? ? ? ? ? ? ? ? ? > Strix_nebulosa ? ? ? ? ? ? ? ? ? ? > Strix_uralensis ? ? ? ? ? ? ? ? ? ? > Surnia_ulula ? ? ? ? ? ? ? ? ? ? > Caprimulgus_ruficollis ? ? ? ? ? ? ? ? ? ? > Columba_bollii ? ? ? ? ? ? ? ? ? ? > Columba_junoniae ? ? ? ? ? ? ? ? ? ? > Columba_trocaz ? ? ? ? ? ? ? ? ? ? > Stigmatopelia_senegalensis ? ? ? ? ? ? ? ? ? ? > Chlamydotis_undulata ? ? ? ? ? ? ? ? ? ? > Otis_tarda ? ? ? ? ? ? ? ? ? ? > Tetrax_tetrax ? ? ? ? ? ? ? ? ? ? > Grus_grus ? ? ? ? ? ? ? ? ? ? > Grus_virgo ? ? ? ? ? ? ? ? ? ? > Fulica_cristata ? ? ? ? ? ? ? ? ? ? > Porphyrio_porphyrio ? ? ? ? ? ? ? ? ? ? > Porzana_parva ? ? ? ? ? ? ? ? ? ? > Porzana_pusilla ? ? ? ? ? ? ? ? ? ? > Pterocles_alchata ? ? ? ? ? ? ? ? ? ? > Pterocles_orientalis ? ? ? ? ? ? ? ? ? ? > Arenaria_interpres ? ? ? ? ? ? ? ? ? ? > Calidris_alba ? ? ? ? ? ? ? ? ? ? > Calidris_bairdii ? ? ? ? ? ? ? ? ? ? > Calidris_maritima ? ? ? ? ? ? ? ? ? ? > Calidris_temminckii ? ? ? ? ? ? ? ? ? ? > Gallinago_media ? ? ? ? ? ? ? ? ? ? > Limicola_falcinellus ? ? ? ? ? ? ? ? ? ? > Limosa_lapponica ? ? ? ? ? ? ? ? ? ? > Lymnocryptes_minimus ? ? ? ? ? ? ? ? ? ? > Phalaropus_fulicarius ? ? ? ? ? ? ? ? ? ? > Tringa_erythropus ? ? ? ? ? ? ? ? ? ? > Tringa_glareola ? ? ? ? ? ? ? ? ? ? > Tringa_ochropus ? ? ? ? ? ? ? ? ? ? > Tringa_stagnatilis ? ? ? ? ? ? ? ? ? ? > Xenus_cinereus ? ? ? ? ? ? ? ? ? ? > Charadrius_alexandrinus ? ? ? ? ? ? ? ? ? ? > Charadrius_asiaticus ? ? ? ? ? ? ? ? ? ? > Charadrius_leschenaultii ? ? ? ? ? ? ? ? ? ? > Vanellus_indicus ? ? ? ? ? ? ? ? ? ? > Vanellus_spinosus ? ? ? ? ? ? ? ? ? ? > Cursorius_cursor ? ? ? ? ? ? ? ? ? ? > Glareola_nordmanni ? ? ? ? ? ? ? ? ? ? > Glareola_pratincola ? ? ? ? ? ? ? ? ? ? > Larus_armenicus ? ? ? ? ? ? ? ? ? ? > Larus_audouinii ? ? ? ? ? ? ? ? ? ? > Larus_genei ? ? ? ? ? ? ? ? ? ? > Larus_glaucoides ? ? ? ? ? ? ? ? ? ? > Larus_hyperboreus ? ? ? ? ? ? ? ? ? ? > Larus_ichthyaetus ? ? ? ? ? ? ? ? ? ? > Larus_minutus ? ? ? ? ? ? ? ? ? ? > Pagophila_eburnea ? ? ? ? ? ? ? ? ? ? > Accipiter_badius ? ? ? ? ? ? ? ? ? ? > Accipiter_brevipes ? ? ? ? ? ? ? ? ? ? > Aegypius_monachus ? ? ? ? ? ? ? ? ? ? > Aquila_adalberti ? ? ? ? ? ? ? ? ? ? > Aquila_clanga ? ? ? ? ? ? ? ? ? ? > Aquila_heliaca ? ? ? ? ? ? ? ? ? ? > Aquila_nipalensis ? ? ? ? ? ? ? ? ? ? > Aquila_pomarina ? ? ? ? ? ? ? ? ? ? > Buteo_lagopus ? ? ? ? ? ? ? ? ? ? > Buteo_rufinus ? ? ? ? ? ? ? ? ? ? > Circaetus_gallicus ? ? ? ? ? ? ? ? ? ? > Circus_macrourus ? ? ? ? ? ? ? ? ? ? > Circus_pygargus ? ? ? ? ? ? ? ? ? ? > Elanus_caeruleus ? ? ? ? ? ? ? ? ? ? > Gypaetus_barbatus ? ? ? ? ? ? ? ? ? ? > Gyps_fulvus ? ? ? ? ? ? ? ? ? ? > Hieraaetus_fasciatus ? ? ? ? ? ? ? ? ? ? > Hieraaetus_pennatus ? ? ? ? ? ? ? ? ? ? > Milvus_migrans ? ? ? ? ? ? ? ? ? ? > Neophron_percnopterus ? ? ? ? ? ? ? ? ? ? > Alle_alle ? ? ? ? ? ? ? ? ? ? > Uria_lomvia ? ? ? ? ? ? ? ? ? ? > Himantopus_himantopus ? ? ? ? ? ? ? ? ? ? > Falco_biarmicus ? ? ? ? ? ? ? ? ? ? > Falco_cherrug ? ? ? ? ? ? ? ? ? ? > Falco_eleonorae ? ? ? ? ? ? ? ? ? ? > Falco_naumanni ? ? ? ? ? ? ? ? ? ? > Falco_pelerinoides ? ? ? ? ? ? ? ? ? ? > Falco_rusticolus ? ? ? ? ? ? ? ? ? ? > Falco_vespertinus ? ? ? ? ? ? ? ? ? ? > Podiceps_grisegena ? ? ? ? ? ? ? ? ? ? > Phaethon_aethereus ? ? ? ? ? ? ? ? ? ? > Phalacrocorax_pygmeus ? ? ? ? ? ? ? ? ? ? > Ardea_purpurea ? ? ? ? ? ? ? ? ? ? > Ardeola_ralloides ? ? ? ? ? ? ? ? ? ? > Bubulcus_ibis ? ? ? ? ? ? ? ? ? ? > Egretta_alba ? ? ? ? ? ? ? ? ? ? > Ixobrychus_minutus ? ? ? ? ? ? ? ? ? ? > Nycticorax_nycticorax ? ? ? ? ? ? ? ? ? ? > Phoenicopterus_ruber ? ? ? ? ? ? ? ? ? ? > Platalea_leucorodia ? ? ? ? ? ? ? ? ? ? > Plegadis_falcinellus ? ? ? ? ? ? ? ? ? ? > Pelecanus_crispus ? ? ? ? ? ? ? ? ? ? > Pelecanus_onocrotalus ? ? ? ? ? ? ? ? ? ? > Ciconia_ciconia ? ? ? ? ? ? ? ? ? ? > Ciconia_nigra ? ? ? ? ? ? ? ? ? ? > Fregata_magnificens ? ? ? ? ? ? ? ? ? ? > Gavia_immer ? ? ? ? ? ? ? ? ? ? > Oceanites_oceanicus ? ? ? ? ? ? ? ? ? ? > Pelagodroma_marina ? ? ? ? ? ? ? ? ? ? > Bulweria_bulwerii ? ? ? ? ? ? ? ? ? ? > Calonectris_diomedea ? ? ? ? ? ? ? ? ? ? > Pterodroma_feae ? ? ? ? ? ? ? ? ? ? > Pterodroma_madeira ? ? ? ? ? ? ? ? ? ? > Puffinus_assimilis ? ? ? ? ? ? ? ? ? ? > Puffinus_gravis ? ? ? ? ? ? ? ? ? ? > Puffinus_griseus ? ? ? ? ? ? ? ? ? ? > Puffinus_mauretanicus ? ? ? ? ? ? ? ? ? ? > Puffinus_yelkouan ? ? ? ? ? ? ? ? ? ? > Lanius_collurio ? ? ? ? ? ? ? ? ? ? > Lanius_excubitor ? ? ? ? ? ? ? ? ? ? > Lanius_isabellinus ? ? ? ? ? ? ? ? ? ? > Lanius_minor ? ? ? ? ? ? ? ? ? ? > Lanius_nubicus ? ? ? ? ? ? ? ? ? ? > Lanius_senator ? ? ? ? ? ? ? ? ? ? > Cyanopica_cyanus ? ? ? ? ? ? ? ? ? ? > Nucifraga_caryocatactes ? ? ? ? ? ? ? ? ? ? > Perisoreus_infaustus ? ? ? ? ? ? ? ? ? ? > Pyrrhocorax_graculus ? ? ? ? ? ? ? ? ? ? > Sturnus_roseus ? ? ? ? ? ? ? ? ? ? > Sturnus_unicolor ? ? ? ? ? ? ? ? ? ? > Bombycilla_garrulus ? ? ? ? ? ? ? ? ? ? > Cercotrichas_galactotes ? ? ? ? ? ? ? ? ? ? > Ficedula_albicollis ? ? ? ? ? ? ? ? ? ? > Ficedula_parva ? ? ? ? ? ? ? ? ? ? > Chlidonias_hybrida ? ? ? ? ? ? ? ? ? ? > Chlidonias_leucopterus ? ? ? ? ? ? ? ? ? ? > Chlidonias_niger ? ? ? ? ? ? ? ? ? ? > Sterna_caspia ? ? ? ? ? ? ? ? ? ? > Sitta_krueperi ? ? ? ? ? ? ? ? ? ? > Sitta_neumayer ? ? ? ? ? ? ? ? ? ? > Sitta_whiteheadi ? ? ? ? ? ? ? ? ? ? > Certhia_brachydactyla ? ? ? ? ? ? ? ? ? ? > Parus_cinctus ? ? ? ? ? ? ? ? ? ? > Parus_cyanus ? ? ? ? ? ? ? ? ? ? > Parus_lugubris ? ? ? ? ? ? ? ? ? ? > Hirundo_daurica ? ? ? ? ? ? ? ? ? ? > Hirundo_rupestris ? ? ? ? ? ? ? ? ? ? > Pycnonotus_xanthopygos ? ? ? ? ? ? ? ? ? ? > Cisticola_juncidis ? ? ? ? ? ? ? ? ? ? > Prinia_gracilis ? ? ? ? ? ? ? ? ? ? > Luscinia_calliope ? ? ? ? ? ? ? ? ? ? > Luscinia_luscinia ? ? ? ? ? ? ? ? ? ? > Luscinia_svecica ? ? ? ? ? ? ? ? ? ? > Monticola_saxatilis ? ? ? ? ? ? ? ? ? ? > Monticola_solitarius ? ? ? ? ? ? ? ? ? ? > Oenanthe_deserti ? ? ? ? ? ? ? ? ? ? > Oenanthe_finschii ? ? ? ? ? ? ? ? ? ? > Oenanthe_hispanica ? ? ? ? ? ? ? ? ? ? > Oenanthe_isabellina ? ? ? ? ? ? ? ? ? ? > Oenanthe_leucura ? ? ? ? ? ? ? ? ? ? > Oenanthe_pleschanka ? ? ? ? ? ? ? ? ? ? > Oenanthe_xanthoprymna ? ? ? ? ? ? ? ? ? ? > Tarsiger_cyanurus ? ? ? ? ? ? ? ? ? ? > Turdus_ruficollis ? ? ? ? ? ? ? ? ? ? > Acrocephalus_agricola ? ? ? ? ? ? ? ? ? ? > Acrocephalus_arundinaceus ? ? ? ? ? ? ? ? ? ? > Acrocephalus_dumetorum ? ? ? ? ? ? ? ? ? ? > Acrocephalus_melanopogon ? ? ? ? ? ? ? ? ? ? > Acrocephalus_paludicola ? ? ? ? ? ? ? ? ? ? > Hippolais_caligata ? ? ? ? ? ? ? ? ? ? > Hippolais_icterina ? ? ? ? ? ? ? ? ? ? > Hippolais_languida ? ? ? ? ? ? ? ? ? ? > Hippolais_olivetorum ? ? ? ? ? ? ? ? ? ? > Hippolais_opaca ? ? ? ? ? ? ? ? ? ? > Hippolais_pallida ? ? ? ? ? ? ? ? ? ? > Hippolais_polyglotta ? ? ? ? ? ? ? ? ? ? > Locustella_lanceolata ? ? ? ? ? ? ? ? ? ? > Locustella_luscinioides ? ? ? ? ? ? ? ? ? ? > Phylloscopus_bonelli ? ? ? ? ? ? ? ? ? ? > Phylloscopus_borealis ? ? ? ? ? ? ? ? ? ? > Phylloscopus_canariensis ? ? ? ? ? ? ? ? ? ? > Phylloscopus_fuscatus ? ? ? ? ? ? ? ? ? ? > Phylloscopus_ibericus ? ? ? ? ? ? ? ? ? ? > Phylloscopus_inornatus ? ? ? ? ? ? ? ? ? ? > Phylloscopus_sindianus ? ? ? ? ? ? ? ? ? ? > Phylloscopus_trochiloides ? ? ? ? ? ? ? ? ? ? > Sylvia_cantillans ? ? ? ? ? ? ? ? ? ? > Sylvia_conspicillata ? ? ? ? ? ? ? ? ? ? > Sylvia_hortensis ? ? ? ? ? ? ? ? ? ? > Sylvia_melanocephala ? ? ? ? ? ? ? ? ? ? > Sylvia_melanothorax ? ? ? ? ? ? ? ? ? ? > Sylvia_mystacea ? ? ? ? ? ? ? ? ? ? > Sylvia_nana ? ? ? ? ? ? ? ? ? ? > Sylvia_nisoria ? ? ? ? ? ? ? ? ? ? > Sylvia_rueppelli ? ? ? ? ? ? ? ? ? ? > Sylvia_sarda ? ? ? ? ? ? ? ? ? ? > Ammomanes_deserti ? ? ? ? ? ? ? ? ? ? > Calandrella_brachydactyla ? ? ? ? ? ? ? ? ? ? > Calandrella_rufescens ? ? ? ? ? ? ? ? ? ? > Chersophilus_duponti ? ? ? ? ? ? ? ? ? ? > Eremophila_alpestris ? ? ? ? ? ? ? ? ? ? > Galerida_cristata ? ? ? ? ? ? ? ? ? ? > Galerida_theklae ? ? ? ? ? ? ? ? ? ? > Melanocorypha_bimaculata ? ? ? ? ? ? ? ? ? ? > Melanocorypha_calandra ? ? ? ? ? ? ? ? ? ? > Melanocorypha_leucoptera ? ? ? ? ? ? ? ? ? ? > Melanocorypha_yeltoniensis ? ? ? ? ? ? ? ? ? ? > Montifringilla_nivalis ? ? ? ? ? ? ? ? ? ? > Passer_hispaniolensis ? ? ? ? ? ? ? ? ? ? > Petronia_petronia ? ? ? ? ? ? ? ? ? ? > Bucanetes_githagineus ? ? ? ? ? ? ? ? ? ? > Carduelis_hornemanni ? ? ? ? ? ? ? ? ? ? > Carpodacus_erythrinus ? ? ? ? ? ? ? ? ? ? > Carpodacus_rubicilla ? ? ? ? ? ? ? ? ? ? > Loxia_leucoptera ? ? ? ? ? ? ? ? ? ? > Loxia_pytyopsittacus ? ? ? ? ? ? ? ? ? ? > Pinicola_enucleator ? ? ? ? ? ? ? ? ? ? > Pyrrhula_murina ? ? ? ? ? ? ? ? ? ? > Rhodopechys_mongolicus ? ? ? ? ? ? ? ? ? ? > Serinus_canaria ? ? ? ? ? ? ? ? ? ? > Serinus_citrinella ? ? ? ? ? ? ? ? ? ? > Serinus_pusillus ? ? ? ? ? ? ? ? ? ? > Serinus_serinus ? ? ? ? ? ? ? ? ? ? > Tichodroma_muraria ? ? ? ? ? ? ? ? ? ? > Remiz_pendulinus ? ? ? ? ? ? ? ? ? ? > Prunella_atrogularis ? ? ? ? ? ? ? ? ? ? > Prunella_collaris ? ? ? ? ? ? ? ? ? ? > Prunella_montanella ? ? ? ? ? ? ? ? ? ? > Anthus_berthelotii ? ? ? ? ? ? ? ? ? ? > Anthus_campestris ? ? ? ? ? ? ? ? ? ? > Anthus_cervinus ? ? ? ? ? ? ? ? ? ? > Anthus_hodgsoni ? ? ? ? ? ? ? ? ? ? > Anthus_spinoletta ? ? ? ? ? ? ? ? ? ? > Motacilla_citreola ? ? ? ? ? ? ? ? ? ? > Calcarius_lapponicus ? ? ? ? ? ? ? ? ? ? > Emberiza_aureola ? ? ? ? ? ? ? ? ? ? > Emberiza_bruniceps ? ? ? ? ? ? ? ? ? ? > Emberiza_caesia ? ? ? ? ? ? ? ? ? ? > Emberiza_cia ? ? ? ? ? ? ? ? ? ? > Emberiza_cineracea ? ? ? ? ? ? ? ? ? ? > Emberiza_hortulana ? ? ? ? ? ? ? ? ? ? > Emberiza_leucocephalos ? ? ? ? ? ? ? ? ? ? > Emberiza_melanocephala ? ? ? ? ? ? ? ? ? ? > Emberiza_pallasi ? ? ? ? ? ? ? ? ? ? > Emberiza_pusilla ? ? ? ? ? ? ? ? ? ? > Emberiza_rustica ? ? ? ? ? ? ? ? ? ? > > ; > > END; > BEGIN TREES; > Title Imported_trees; > LINK Taxa = Taxa; > TRANSLATE > 1 Alectoris_barbara, > 2 Alectoris_chuckar, > 3 Alectoris_graeca, > 4 Ammoperdix_griseogularis, > 5 Bonasa_Bonasia, > 6 Francolinus_francolinus, > 7 Tetrao_mlokosiewiczi, > 8 Tetraogallus_caspius, > 9 Tetraogallus_caucasiucus, > 10 Anser_albifrons, > 11 Anser_brachyrhynchus, > 12 Anser_erythropus, > 13 Anser_fabalis, > 14 Aythya_marila, > 15 Aythya_nyroca, > 16 Branta_bernicla, > 17 Branta_canadensis, > 18 Branta_leucopsis, > 19 Branta_ruficollis, > 20 Bucephala_islandica, > 21 Chen_caerulescens, > 22 Clangula_hyemalis, > 23 Cygnus_columbianus, > 24 Cygnus_cygnus, > 25 Histrionicus_histrionicus, > 26 Marmaronetta_angustirostris, > 27 Melanitta_fusca, > 28 Melanitta_perspicillata, > 29 Netta_rufina, > 30 Oxyura_leucocephala, > 31 Polysticta_stelleri, > 32 Somateria_spectabilis, > 33 Tadorna_ferruginea, > 34 Dendrocopos_leucotos, > 35 Dendrocopos_medius, > 36 Dendrocopos_syriacus, > 37 Dryocopus_martius, > 38 Jynx_torquilla, > 39 Picoides_tridactylus, > 40 Picus_canus, > 41 Upupa_epops, > 42 Coracias_garrulus, > 43 Merops_apiaster, > 44 Merops_persicus, > 45 Ceryle_rudis, > 46 Halcyon_smyrnensis, > 47 Cuculus_optatus, > 48 Apus_affinis, > 49 Apus_caffer, > 50 Apus_pallidus, > 51 Apus_unicolor, > 52 Tachymarptis_melba, > 53 Aegolius_funereus, > 54 Bubo_bubo, > 55 Bubo_scandiaca, > 56 Glaucidium_passerinum, > 57 Ketupa_zeylonensis, > 58 Otus_brucei, > 59 Otus_scops, > 60 Strix_nebulosa, > 61 Strix_uralensis, > 62 Surnia_ulula, > 63 Caprimulgus_ruficollis, > 64 Columba_bollii, > 65 Columba_junoniae, > 66 Columba_trocaz, > 67 Stigmatopelia_senegalensis, > 68 Chlamydotis_undulata, > 69 Otis_tarda, > 70 Tetrax_tetrax, > 71 Grus_grus, > 72 Grus_virgo, > 73 Fulica_cristata, > 74 Porphyrio_porphyrio, > 75 Porzana_parva, > 76 Porzana_pusilla, > 77 Pterocles_alchata, > 78 Pterocles_orientalis, > 79 Arenaria_interpres, > 80 Calidris_alba, > 81 Calidris_bairdii, > 82 Calidris_maritima, > 83 Calidris_temminckii, > 84 Gallinago_media, > 85 Limicola_falcinellus, > 86 Limosa_lapponica, > 87 Lymnocryptes_minimus, > 88 Phalaropus_fulicarius, > 89 Tringa_erythropus, > 90 Tringa_glareola, > 91 Tringa_ochropus, > 92 Tringa_stagnatilis, > 93 Xenus_cinereus, > 94 Charadrius_alexandrinus, > 95 Charadrius_asiaticus, > 96 Charadrius_leschenaultii, > 97 Vanellus_indicus, > 98 Vanellus_spinosus, > 99 Cursorius_cursor, > 100 Glareola_nordmanni, > 101 Glareola_pratincola, > 102 Larus_armenicus, > 103 Larus_audouinii, > 104 Larus_genei, > 105 Larus_glaucoides, > 106 Larus_hyperboreus, > 107 Larus_ichthyaetus, > 108 Larus_minutus, > 109 Pagophila_eburnea, > 110 Accipiter_badius, > 111 Accipiter_brevipes, > 112 Aegypius_monachus, > 113 Aquila_adalberti, > 114 Aquila_clanga, > 115 Aquila_heliaca, > 116 Aquila_nipalensis, > 117 Aquila_pomarina, > 118 Buteo_lagopus, > 119 Buteo_rufinus, > 120 Circaetus_gallicus, > 121 Circus_macrourus, > 122 Circus_pygargus, > 123 Elanus_caeruleus, > 124 Gypaetus_barbatus, > 125 Gyps_fulvus, > 126 Hieraaetus_fasciatus, > 127 Hieraaetus_pennatus, > 128 Milvus_migrans, > 129 Neophron_percnopterus, > 130 Alle_alle, > 131 Uria_lomvia, > 132 Himantopus_himantopus, > 133 Falco_biarmicus, > 134 Falco_cherrug, > 135 Falco_eleonorae, > 136 Falco_naumanni, > 137 Falco_pelerinoides, > 138 Falco_rusticolus, > 139 Falco_vespertinus, > 140 Podiceps_grisegena, > 141 Phaethon_aethereus, > 142 Phalacrocorax_pygmeus, > 143 Ardea_purpurea, > 144 Ardeola_ralloides, > 145 Bubulcus_ibis, > 146 Egretta_alba, > 147 Ixobrychus_minutus, > 148 Nycticorax_nycticorax, > 149 Phoenicopterus_ruber, > 150 Platalea_leucorodia, > 151 Plegadis_falcinellus, > 152 Pelecanus_crispus, > 153 Pelecanus_onocrotalus, > 154 Ciconia_ciconia, > 155 Ciconia_nigra, > 156 Fregata_magnificens, > 157 Gavia_immer, > 158 Oceanites_oceanicus, > 159 Pelagodroma_marina, > 160 Bulweria_bulwerii, > 161 Calonectris_diomedea, > 162 Pterodroma_feae, > 163 Pterodroma_madeira, > 164 Puffinus_assimilis, > 165 Puffinus_gravis, > 166 Puffinus_griseus, > 167 Puffinus_mauretanicus, > 168 Puffinus_yelkouan, > 169 Lanius_collurio, > 170 Lanius_excubitor, > 171 Lanius_isabellinus, > 172 Lanius_minor, > 173 Lanius_nubicus, > 174 Lanius_senator, > 175 Cyanopica_cyanus, > 176 Nucifraga_caryocatactes, > 177 Perisoreus_infaustus, > 178 Pyrrhocorax_graculus, > 179 Sturnus_roseus, > 180 Sturnus_unicolor, > 181 Bombycilla_garrulus, > 182 Cercotrichas_galactotes, > 183 Ficedula_albicollis, > 184 Ficedula_parva, > 185 Chlidonias_hybrida, > 186 Chlidonias_leucopterus, > 187 Chlidonias_niger, > 188 Sterna_caspia, > 189 Sitta_krueperi, > 190 Sitta_neumayer, > 191 Sitta_whiteheadi, > 192 Certhia_brachydactyla, > 193 Parus_cinctus, > 194 Parus_cyanus, > 195 Parus_lugubris, > 196 Hirundo_daurica, > 197 Hirundo_rupestris, > 198 Pycnonotus_xanthopygos, > 199 Cisticola_juncidis, > 200 Prinia_gracilis, > 201 Luscinia_calliope, > 202 Luscinia_luscinia, > 203 Luscinia_svecica, > 204 Monticola_saxatilis, > 205 Monticola_solitarius, > 206 Oenanthe_deserti, > 207 Oenanthe_finschii, > 208 Oenanthe_hispanica, > 209 Oenanthe_isabellina, > 210 Oenanthe_leucura, > 211 Oenanthe_pleschanka, > 212 Oenanthe_xanthoprymna, > 213 Tarsiger_cyanurus, > 214 Turdus_ruficollis, > 215 Acrocephalus_agricola, > 216 Acrocephalus_arundinaceus, > 217 Acrocephalus_dumetorum, > 218 Acrocephalus_melanopogon, > 219 Acrocephalus_paludicola, > 220 Hippolais_caligata, > 221 Hippolais_icterina, > 222 Hippolais_languida, > 223 Hippolais_olivetorum, > 224 Hippolais_opaca, > 225 Hippolais_pallida, > 226 Hippolais_polyglotta, > 227 Locustella_lanceolata, > 228 Locustella_luscinioides, > 229 Phylloscopus_bonelli, > 230 Phylloscopus_borealis, > 231 Phylloscopus_canariensis, > 232 Phylloscopus_fuscatus, > 233 Phylloscopus_ibericus, > 234 Phylloscopus_inornatus, > 235 Phylloscopus_sindianus, > 236 Phylloscopus_trochiloides, > 237 Sylvia_cantillans, > 238 Sylvia_conspicillata, > 239 Sylvia_hortensis, > 240 Sylvia_melanocephala, > 241 Sylvia_melanothorax, > 242 Sylvia_mystacea, > 243 Sylvia_nana, > 244 Sylvia_nisoria, > 245 Sylvia_rueppelli, > 246 Sylvia_sarda, > 247 Ammomanes_deserti, > 248 Calandrella_brachydactyla, > 249 Calandrella_rufescens, > 250 Chersophilus_duponti, > 251 Eremophila_alpestris, > 252 Galerida_cristata, > 253 Galerida_theklae, > 254 Melanocorypha_bimaculata, > 255 Melanocorypha_calandra, > 256 Melanocorypha_leucoptera, > 257 Melanocorypha_yeltoniensis, > 258 Montifringilla_nivalis, > 259 Passer_hispaniolensis, > 260 Petronia_petronia, > 261 Bucanetes_githagineus, > 262 Carduelis_hornemanni, > 263 Carpodacus_erythrinus, > 264 Carpodacus_rubicilla, > 265 Loxia_leucoptera, > 266 Loxia_pytyopsittacus, > 267 Pinicola_enucleator, > 268 Pyrrhula_murina, > 269 Rhodopechys_mongolicus, > 270 Serinus_canaria, > 271 Serinus_citrinella, > 272 Serinus_pusillus, > 273 Serinus_serinus, > 274 Tichodroma_muraria, > 275 Remiz_pendulinus, > 276 Prunella_atrogularis, > 277 Prunella_collaris, > 278 Prunella_montanella, > 279 Anthus_berthelotii, > 280 Anthus_campestris, > 281 Anthus_cervinus, > 282 Anthus_hodgsoni, > 283 Anthus_spinoletta, > 284 Motacilla_citreola, > 285 Calcarius_lapponicus, > 286 Emberiza_aureola, > 287 Emberiza_bruniceps, > 288 Emberiza_caesia, > 289 Emberiza_cia, > 290 Emberiza_cineracea, > 291 Emberiza_hortulana, > 292 Emberiza_leucocephalos, > 293 Emberiza_melanocephala, > 294 Emberiza_pallasi, > 295 Emberiza_pusilla, > 296 Emberiza_rustica; > TREE 'Imported tree 0+' = > ((1:5.0,2:5.0,3:5.0):2.0,(4:5.0):2.0,(5:5.0):2.0,(6:5.0):2.0,(7:5.0):2.0,(8:5.0,9:5.0):2.0):22.9,(10:5.0,11:5.0,12:5.0,13:5.0):2.0):5.1,(((34:5.0,35:5.0,36:5.0,37:5.0):2.0,(38:5.0):2.0,(39:5.0):2.0,(40:5.0):2.0):26.3,((41:5.0):2.0):23.4,(((42:5.0):2.0):21.0,((43:5.0,44:5.0):2.0):19.7,((45:5.0):2.0,(46:5.0):2.0):19.7):1.3):2.4):1.6,(((47:5.0):2.0):23.7)),((48:5.0,49:5.0,50:5.0,51:5.0):2.0,(52:5.0):2.0):21.9,((((53:5.0):2.0,(54:5.0,55:5.0):2.0,(56:5.0):2.0,(57:5.0):2.0,(58:5.0,59:5.0):2.0,(60:5.0,61:5.0):2.0,(62:5.0):2.0):19.1,((63:5.0):2.0):19.1):2.8):0.6,((((64:5.0,65:5.0,66:5.0):2.0,(67:5.0):2.0):20.8,(((((68:5.0):2.0,(69:5.0):2.0,(70:5.0):2.0):16.9,((71:5.0,72:5.0):2.0):16.9):2.2,((73:5.0):2.0,(74:5.0):2.0,(75:5.0,76:5.0):2.0):19.1):1.0,((((77:5.0,78:5.0):2.0):17.1,(((79:5.0):2.0,(80:5.0,81:5.0,82:5.0,83:5.0):2.0,(84:5.0):2.0,(85:5.0):2.0,(86:5.0):2.0,(87:5.0):2.0,(88:5.0):2.0,(89:5.0,90:5.0,91:5.0,92:5.0):2.0,(93:5.0):2.0):15.6,(((94:5.0,95:5.0,96:5.0)2,(97:5.0,98:5.0):2.0 > ):12.8,(((99):5.0):2.0,(100:5.0,101:5.0):2.0):8.1,((102:5.0,103:5.0,104:5.0,105:5.0,106:5.0,107:5.0,108:5.0):2.0,(109:5.0):2.0):8.1):4.7):2.8):1.5):1.6,((((110:5.0,111:5.0):2.0,(112:5.0):2.0,(113:5.0,114:5.0,115:5.0,116:5.0,117:5.0):2.0,(118:5.0,119:5.0):2.0,(120:5.0):2.0,(121:5.0,122:5.0):2.0,(123:5.0):2.0,(124:5.0):2.0,(125:5.0):2.0,(126:5.0,127:5.0):2.0,(128:5.0):2.0,(129:5.0):2.0):15.2,((130:5.0):2.0,(131:5.0):2.0):15.2,((132:5.0):2.0):15.2,((133:5.0,134:5.0,135:5.0,136:5.0,137:5.0,138:5.0,139:5.0):2.0):15.2):1.2,(((140:5.0):2.0):14.9,(((141:5.0):2.0):14.0,(((142:5.0):2.0):13.3,(((143:5.0):2.0,(144:5.0):2.0,(145:5.0):2.0,(146:5.0):2.0,(147:5.0):2.0,(148:5.0):2.0):12.4,(((149:5.0):2.0):11.5,(((150:5.0):2.0,(151:5.0):2.0):11.1,((((152:5.0,153:5.0):2.0):10.1,((154:5.0,155:5.0):2.0):10.1):0.8,(((156:5.0):2.0):10.7,(((157:5.0):2.0):10.0,((158:5.0):2.0,(159:5.0):2.0):10.0,((160:5.0):2.0,(161:5.0):2.0,(162:5.0):2.0,163:5.0):2.0,(164:5.0,165:5.0,166:5.0,167:5.0,168:5.0):2.0):10. > 0):0.7):0.2):0.2):0.4):0.9):0.9):0.7):0.9):1.5):2.3):1.4):0.7):0.8,((((169:5.0,170:5.0,171:5.0,172:5.0,173:5.0,174:5.0):2.0):9.1,((175:5.0):2.0,(176:5.0):2.0,(177:5.0):2.0,(178:5.0):2.0,(179:5.0,180:5.0):2.0):9.1):3.7,((((181:5.0):2.0):10.6,(((182:5.0):2.0,(183:5.0,184:5.0):2.0):9.1,((185:5.0,186:5.0,187:5.0):2.0,(188:5.0):2.0):9.1):1.5):1.1,(((((189:5.0,190:5.0,191:5.0):2.0):10.0,((192:5.0):2.0):10.0):0.8,(((193:5.0,194:5.0,195:5.0):2.0):10.6,(((196:5.0,197:5.0):2.0):10.1,(((198:5.0):2.0):9.5,(((199:5.0):2.0,(200:5.0):2.0):9.4,((201:5.0,202:5.0,203:5.0):2.0,(204:5.0,205:5.0):2.0,(206:5.0,207:5.0,208:5.0,209:5.0,210:5.0,211:5.0,212:5.0):2.0,(213:5.0):2.0,214:7.0):9.4,((215:5.0,216:5.0,217:5.0,218:5.0,219:5.0):2.0,(220:5.0,221:5.0,222:5.0,223:5.0,224:5.0,225:5.0,226:5.0):2.0,(227:5.0,228:5.0):2.0,(229:5.0,230:5.0,231:5.0,232:5.0,233:5.0,234:5.0,235:5.0,236:5.0):2.0,(237:5.0,238:5.0,239:5.0,240:5.0,241:5.0,242:5.0,243:5.0,244:5.0,245:5.0,246:5.0):2.0):9.4):0.1):0.6):0.5):0.2): > 0.3,(((247:5.0):2.0,(248:5.0,249:5.0):2.0,(250:5.0):2.0,(251:5.0):2.0,(252:5.0,253:5.0):2.0,(254:5.0,255:5.0,256:5.0,257:5.0):2.0):10.4,(((258:5.0,259:5.0,260:5.0):2.0):10.0,(261:5.0):2.0,(262:5.0):2.0,(263:5.0,264:5.0):2.0,(265:5.0,266:5.0):2.0,(267:5.0):2.0,(268:5.0):2.0,(269:5.0):2.0,(270:5.0,271:5.0,272:5.0,273:5.0):2.0):10.0,((274:5.0):2.0):10.0,((275:5.0):2.0):10.0,((276:5.0,277:5.0,278:5.0):2.0):10.0,((279:5.0,280:5.0,281:5.0,282:5.0,283:5.0):2.0,(284:5.0):2.0):10.0,(285:5.0):2.0,(286:5.0,287:5.0,288:5.0,289:5.0,290:5.0,291:5.0,292:5.0,293:5.0,294:5.0,295:5.0,296:5.0):2.0):10.0):0.4):0.7):0.6):1.1; > > END; > > > BEGIN ASSUMPTIONS; > TYPESET * UNTITLED (CHARACTERS = Categorical) = unord: 1 - 7; > TYPESET * UNTITLED (CHARACTERS = Continuous) = Squared: 1 - 10; > > END; > > BEGIN CODONS; > CODESET * UNTITLED (CHARACTERS = Categorical) = universal: 1 - 7; > > > END; > > BEGIN MESQUITECHARMODELS; > ProbModelSet * UNTITLED (CHARACTERS = Categorical) = 'Mk1 (est.)': 1 - 7; > ProbModelSet * UNTITLED (CHARACTERS = Continuous) = Brownian_default: 1 - > 10; > END; > > Begin MESQUITE; > MESQUITESCRIPTVERSION 2; > TITLE AUTO; > tell ProjectCoordinator; > getEmployee #mesquite.minimal.ManageTaxa.ManageTaxa; > tell It; > setID 0 7489305339335140846; > endTell; > getEmployee #mesquite.charMatrices.ManageCharacters.ManageCharacters; > tell It; > setID 0 3534675600459598498; > checksum 0 500806229 null; > setID 1 6456195826553758366; > checksum 1 1538862558 null; > endTell; > getWindow; > tell It; > setResourcesState false false 542; > setPopoutState 400; > setExplanationSize 0; > setAnnotationSize 0; > setFontIncAnnot 0; > setFontIncExp 0; > setSize 1425 800; > setLocation 7 22; > setFont SanSerif; > setFontSize 10; > endTell; > getEmployee #mesquite.minimal.ManageTaxa.ManageTaxa; > tell It; > showTaxa #7489305339335140846 #mesquite.lists.TaxonList.TaxonList; > tell It; > setTaxa #7489305339335140846; > getWindow; > tell It; > newAssistant #mesquite.lists.DefaultTaxaOrder.DefaultTaxaOrder; > newAssistant #mesquite.lists.TaxonListCurrPartition.TaxonListCurrPartition; > getTable; > tell It; > rowNamesWidth 146; > endTell; > setExplanationSize 30; > setAnnotationSize 20; > setFontIncAnnot 0; > setFontIncExp 0; > setSize 883 733; > setLocation 7 22; > setFont SanSerif; > setFontSize 10; > getToolPalette; > tell It; > endTell; > endTell; > showWindow; > getEmployee #mesquite.lists.TaxonListAnnotPanel.TaxonListAnnotPanel; > tell It; > togglePanel off; > endTell; > endTell; > endTell; > getEmployee #mesquite.trees.BasicTreeWindowCoord.BasicTreeWindowCoord; > tell It; > makeTreeWindow #7489305339335140846 > #mesquite.trees.BasicTreeWindowMaker.BasicTreeWindowMaker; > tell It; > suppressEPCResponse; > setTreeSource #mesquite.trees.StoredTrees.StoredTrees; > tell It; > setTreeBlock 1; > toggleUseWeights off; > endTell; > setAssignedID 4022.1227800525891.8782641391695494615; > getTreeWindow; > tell It; > setExplanationSize 30; > setAnnotationSize 20; > setFontIncAnnot 0; > setFontIncExp 0; > setSize 883 733; > setLocation 7 22; > setFont SanSerif; > setFontSize 10; > getToolPalette; > tell It; > endTell; > setActive; > getTreeDrawCoordinator > #mesquite.trees.BasicTreeDrawCoordinator.BasicTreeDrawCoordinator; > tell It; > suppress; > setTreeDrawer #mesquite.trees.SquareTree.SquareTree; > tell It; > setNodeLocs #mesquite.trees.NodeLocsStandard.NodeLocsStandard; > tell It; > stretchToggle off; > branchLengthsToggle off; > toggleScale on; > toggleBroadScale off; > toggleCenter on; > toggleEven on; > endTell; > setEdgeWidth 6; > orientUp; > toggleCorners off; > endTell; > setBackground White; > setBranchColor Black; > showNodeNumbers off; > showBranchColors on; > labelBranchLengths off; > centerBrLenLabels on; > showBrLensUnspecified on; > showBrLenLabelsOnTerminals on; > setBrLenLabelColor 0 0 255; > setNumBrLenDecimals 6; > desuppress; > getEmployee #mesquite.trees.BasicDrawTaxonNames.BasicDrawTaxonNames; > tell It; > setColor Black; > toggleColorPartition on; > toggleShadePartition off; > toggleNodeLabels on; > toggleCenterNodeNames off; > toggleShowNames on; > namesAngle ?; > endTell; > endTell; > setTreeNumber 1; > setTree '(((((((1:5.0,2:5.0,3:5.0):2.0,(4:5.0):2.0,(5:5.0):2.0,(6:5.0):2.0,(7:5.0):2.0,(8:5.0,9:5.0):2.0):22.9,(10:5.0,11:5.0,12:5.0,13:5.0):2.0):5.1,(((34:5.0,35:5.0,36:5.0,37:5.0):2.0,(38:5.0):2.0,(39:5.0):2.0,(40:5.0):2.0):26.3,((41:5.0):2.0):23.4,(((42:5.0):2.0):21.0,((43:5.0,44:5.0):2.0):19.7,((45:5.0):2.0,(46:5.0):2.0):19.7):1.3):2.4):1.6,(((47:5.0):2.0):23.7)),((48:5.0,49:5.0,50:5.0,51:5.0):2.0,(52:5.0):2.0):21.9,((((53:5.0):2.0,(54:5.0,55:5.0):2.0,(56:5.0):2.0,(57:5.0):2.0,(58:5.0,59:5.0):2.0,(60:5.0,61:5.0):2.0,(62:5.0):2.0):19.1,((63:5.0):2.0):19.1):2.8):0.6,((((64:5.0,65:5.0,66:5.0):2.0,(67:5.0):2.0):20.8,(((((68:5.0):2.0,(69:5.0):2.0,(70:5.0):2.0):16.9,((71:5.0,72:5.0):2.0):16.9):2.2,((73:5.0):2.0,(74:5.0):2.0,(75:5.0,76:5.0):2.0):19.1):1.0,((((77:5.0,78:5.0):2.0):17.1,(((79:5.0):2.0,(80:5.0,81:5.0,82:5.0,83:5.0):2.0,(84:5.0):2.0,(85:5.0):2.0,(86:5.0):2.0,(87:5.0):2.0,(88:5.0):2.0,(89:5.0,90:5.0,91:5.0,92:5.0):2.0,(93:5.0):2.0):15.6,(((94:5.0,95:5.0,96:5.0)2, > (97:5.0,98:5.0):2.0):12.8,(((99):5.0):2.0,(100:5.0,101:5.0):2.0):8.1,((102:5.0,103:5.0,104:5.0,105:5.0,106:5.0,107:5.0,108:5.0):2.0,(109:5.0):2.0):8.1):4.7):2.8):1.5):1.6,((((110:5.0,111:5.0):2.0,(112:5.0):2.0,(113:5.0,114:5.0,115:5.0,116:5.0,117:5.0):2.0,(118:5.0,119:5.0):2.0,(120:5.0):2.0,(121:5.0,122:5.0):2.0,(123:5.0):2.0,(124:5.0):2.0,(125:5.0):2.0,(126:5.0,127:5.0):2.0,(128:5.0):2.0,(129:5.0):2.0):15.2,((130:5.0):2.0,(131:5.0):2.0):15.2,((132:5.0):2.0):15.2,((133:5.0,134:5.0,135:5.0,136:5.0,137:5.0,138:5.0,139:5.0):2.0):15.2):1.2,(((140:5.0):2.0):14.9,(((141:5.0):2.0):14.0,(((142:5.0):2.0):13.3,(((143:5.0):2.0,(144:5.0):2.0,(145:5.0):2.0,(146:5.0):2.0,(147:5.0):2.0,(148:5.0):2.0):12.4,(((149:5.0):2.0):11.5,(((150:5.0):2.0,(151:5.0):2.0):11.1,((((152:5.0,153:5.0):2.0):10.1,((154:5.0,155:5.0):2.0):10.1):0.8,(((156:5.0):2.0):10.7,(((157:5.0):2.0):10.0,((158:5.0):2.0,(159:5.0):2.0):10.0,((160:5.0):2.0,(161:5.0):2.0,(162:5.0):2.0,163:5.0):2.0,(164:5.0,165:5.0,166:5.0,167:5. > 0,168:5.0):2.0):10.0):0.7):0.2):0.2):0.4):0.9):0.9):0.7):0.9):1.5):2.3):1.4):0.7):0.8,((((169:5.0,170:5.0,171:5.0,172:5.0,173:5.0,174:5.0):2.0):9.1,((175:5.0):2.0,(176:5.0):2.0,(177:5.0):2.0,(178:5.0):2.0,(179:5.0,180:5.0):2.0):9.1):3.7,((((181:5.0):2.0):10.6,(((182:5.0):2.0,(183:5.0,184:5.0):2.0):9.1,((185:5.0,186:5.0,187:5.0):2.0,(188:5.0):2.0):9.1):1.5):1.1,(((((189:5.0,190:5.0,191:5.0):2.0):10.0,((192:5.0):2.0):10.0):0.8,(((193:5.0,194:5.0,195:5.0):2.0):10.6,(((196:5.0,197:5.0):2.0):10.1,(((198:5.0):2.0):9.5,(((199:5.0):2.0,(200:5.0):2.0):9.4,((201:5.0,202:5.0,203:5.0):2.0,(204:5.0,205:5.0):2.0,(206:5.0,207:5.0,208:5.0,209:5.0,210:5.0,211:5.0,212:5.0):2.0,(213:5.0):2.0,214:7.0):9.4,((215:5.0,216:5.0,217:5.0,218:5.0,219:5.0):2.0,(220:5.0,221:5.0,222:5.0,223:5.0,224:5.0,225:5.0,226:5.0):2.0,(227:5.0,228:5.0):2.0,(229:5.0,230:5.0,231:5.0,232:5.0,233:5.0,234:5.0,235:5.0,236:5.0):2.0,(237:5.0,238:5.0,239:5.0,240:5.0,241:5.0,242:5.0,243:5.0,244:5.0,245:5.0,246:5.0):2.0):9.4):0 > .1):0.6):0.5):0.2):0.3,(((247:5.0):2.0,(248:5.0,249:5.0):2.0,(250:5.0):2.0,(251:5.0):2.0,(252:5.0,253:5.0):2.0,(254:5.0,255:5.0,256:5.0,257:5.0):2.0):10.4,(((258:5.0,259:5.0,260:5.0):2.0):10.0,(261:5.0):2.0,(262:5.0):2.0,(263:5.0,264:5.0):2.0,(265:5.0,266:5.0):2.0,(267:5.0):2.0,(268:5.0):2.0,(269:5.0):2.0,(270:5.0,271:5.0,272:5.0,273:5.0):2.0):10.0,((274:5.0):2.0):10.0,((275:5.0):2.0):10.0,((276:5.0,277:5.0,278:5.0):2.0):10.0,((279:5.0,280:5.0,281:5.0,282:5.0,283:5.0):2.0,(284:5.0):2.0):10.0,(285:5.0):2.0,(286:5.0,287:5.0,288:5.0,289:5.0,290:5.0,291:5.0,292:5.0,293:5.0,294:5.0,295:5.0,296:5.0):2.0):10.0):0.4):0.7):0.6):1.1;'; > useSuggestedSize on; > toggleTextOnTree off; > showWindow; > endTell; > desuppressEPCResponse; > getEmployee #mesquite.trees.ColorBranches.ColorBranches; > tell It; > setColor Red; > removeColor off; > endTell; > getEmployee #mesquite.ornamental.BranchNotes.BranchNotes; > tell It; > setAlwaysOn off; > endTell; > getEmployee #mesquite.ornamental.ColorTreeByPartition.ColorTreeByPartition; > tell It; > colorByPartition off; > endTell; > getEmployee #mesquite.ornamental.DrawTreeAssocDoubles.DrawTreeAssocDoubles; > tell It; > setOn on; > setDigits 4; > writeAsPercentage off; > toggleCentred on; > toggleHorizontal on; > setFontSize 10; > setOffset 0 0; > endTell; > getEmployee #mesquite.trees.TreeInfoValues.TreeInfoValues; > tell It; > panelOpen false; > endTell; > endTell; > endTell; > getEmployee #mesquite.charMatrices.BasicDataWindowCoord.BasicDataWindowCoord; > tell It; > showDataWindow #3534675600459598498 > #mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindowMaker; > tell It; > getWindow; > tell It; > setExplanationSize 30; > setAnnotationSize 20; > setFontIncAnnot 0; > setFontIncExp 0; > setSize 883 733; > setLocation 7 22; > setFont SanSerif; > setFontSize 10; > getToolPalette; > tell It; > endTell; > setTool mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindow.arrow; > colorCells #mesquite.charMatrices.NoColor.NoColor; > colorRowNames #mesquite.charMatrices.TaxonGroupColor.TaxonGroupColor; > colorColumnNames #mesquite.charMatrices.CharGroupColor.CharGroupColor; > colorText #mesquite.charMatrices.NoColor.NoColor; > setBackground White; > toggleShowNames on; > toggleShowTaxonNames on; > toggleTight off; > toggleShowChanges on; > toggleSeparateLines off; > toggleShowStates on; > toggleAutoWCharNames on; > toggleShowDefaultCharNames off; > toggleConstrainCW on; > toggleBirdsEye off; > toggleAllowAutosize on; > toggleColorsPanel off; > toggleDiagonal on; > setDiagonalHeight 80; > toggleLinkedScrolling on; > toggleScrollLinkedTables off; > endTell; > showWindow; > getWindow; > tell It; > forceAutosize; > endTell; > getEmployee #mesquite.charMatrices.ColorCells.ColorCells; > tell It; > setColor Red; > removeColor off; > endTell; > getEmployee #mesquite.categ.StateNamesStrip.StateNamesStrip; > tell It; > showStrip off; > endTell; > getEmployee #mesquite.charMatrices.AnnotPanel.AnnotPanel; > tell It; > togglePanel off; > endTell; > getEmployee #mesquite.charMatrices.CharReferenceStrip.CharReferenceStrip; > tell It; > showStrip off; > endTell; > getEmployee #mesquite.charMatrices.QuickKeySelector.QuickKeySelector; > tell It; > autotabOff; > endTell; > getEmployee #mesquite.categ.SmallStateNamesEditor.SmallStateNamesEditor; > tell It; > panelOpen true; > endTell; > endTell; > showDataWindow #6456195826553758366 > #mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindowMaker; > tell It; > getWindow; > tell It; > setExplanationSize 30; > setAnnotationSize 20; > setFontIncAnnot 0; > setFontIncExp 0; > setSize 883 733; > setLocation 7 22; > setFont SanSerif; > setFontSize 10; > getToolPalette; > tell It; > endTell; > setTool mesquite.charMatrices.BasicDataWindowMaker.BasicDataWindow.arrow; > colorCells #mesquite.charMatrices.NoColor.NoColor; > colorRowNames #mesquite.charMatrices.TaxonGroupColor.TaxonGroupColor; > colorColumnNames #mesquite.charMatrices.CharGroupColor.CharGroupColor; > colorText #mesquite.charMatrices.NoColor.NoColor; > setBackground White; > toggleShowNames on; > toggleShowTaxonNames on; > toggleTight off; > toggleShowChanges on; > toggleSeparateLines off; > toggleShowStates on; > toggleAutoWCharNames on; > toggleShowDefaultCharNames off; > toggleConstrainCW on; > toggleBirdsEye off; > toggleAllowAutosize on; > toggleColorsPanel off; > toggleLinkedScrolling on; > toggleScrollLinkedTables off; > endTell; > showWindow; > getWindow; > tell It; > forceAutosize; > endTell; > getEmployee #mesquite.charMatrices.ColorCells.ColorCells; > tell It; > setColor Red; > removeColor off; > endTell; > getEmployee #mesquite.charMatrices.AnnotPanel.AnnotPanel; > tell It; > togglePanel off; > endTell; > getEmployee #mesquite.charMatrices.CharReferenceStrip.CharReferenceStrip; > tell It; > showStrip off; > endTell; > getEmployee #mesquite.cont.ItemsEditorForInfoPanel.ItemsEditorForInfoPanel; > tell It; > panelOpen false; > endTell; > endTell; > endTell; > endTell; > end; > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From Kurt.Hornik at wu-wien.ac.at Sat Nov 29 11:10:30 2008 From: Kurt.Hornik at wu-wien.ac.at (Kurt Hornik) Date: Sat, 29 Nov 2008 11:10:30 +0100 Subject: [Rd] missing parentheses in FAQ (PR#13343) In-Reply-To: <20081127153504.8E3152834615@mail.pubhealth.ku.dk> References: <20081127153504.8E3152834615@mail.pubhealth.ku.dk> Message-ID: <18737.5398.248286.689105@fangorn.hornik.net> >>>>> spluque writes: > Hi, > A couple of missing parenthesis in R-devel's FAQ: Thanks, fixed. -k > ---<---------------cut here---------------start-------------->--- > Index: doc/manual/R-FAQ.texi > =================================================================== > --- doc/manual/R-FAQ.texi (revision 47025) > +++ doc/manual/R-FAQ.texi (working copy) > @@ -7962,7 +7962,7 @@ > @example > eval(substitute(lm(y ~ x + variable), > - list(variable = as.name(varname[1])) > + list(variable = as.name(varname[1])))) > @end example > @noindent > ---<---------------cut here---------------end---------------->--- > Cheers, > -- > Seb > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel From ggrothendieck at gmail.com Sat Nov 29 12:31:11 2008 From: ggrothendieck at gmail.com (Gabor Grothendieck) Date: Sat, 29 Nov 2008 06:31:11 -0500 Subject: [Rd] names generated in list indexing In-Reply-To: <22D850BC39A25742977325ADDE208E770270618DAB@chiexchange02.w2k.jumptrading.com> References: <22D850BC39A25742977325ADDE208E770270618DAB@chiexchange02.w2k.jumptrading.com> Message-ID: <971536df0811290331v7e02351ayc02ef90f29ebc866@mail.gmail.com> Also note the behavior is the same for a non-list vector: > c(b=1)[c('a','b')] b NA 1 but differs for a data frame: > data.frame(b=1)[c('a','b')] Error in `[.data.frame`(data.frame(b = 1), c("a", "b")) : undefined columns selected On Fri, Nov 28, 2008 at 2:03 PM, Vadim Ogranovich wrote: > Dear R-devel, > > When a character vector is used to subscript a list and when some of the subscripts are not present in the list names R returns NULL for those subscripts and generate NA names for each of them: > >> list(b=1)[c('a','b')] > $ <<-- generated name > NULL > $b > [1] 1 > > > Wouldn't it be more intuitive to use the subscript name rather than to generate an NA? Something like this (not real result): >> list(b=1)[c('a','b')] > $a <<-- more intuitive name > NULL > $b > [1] 1 > > >> version > _ > platform i386-pc-mingw32 > arch i386 > os mingw32 > system i386, mingw32 > status > major 2 > minor 7.1 > year 2008 > month 06 > day 23 > svn rev 45970 > language R > version.string R version 2.7.1 (2008-06-23) >> > > > Thanks, > Vadim > > ________________________________ > Note: This email is for the confidential use of the named addressee(s) only and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you are hereby notified that any review, dissemination or copying of this email is strictly prohibited, and to please notify the sender immediately and destroy this email and any attachments. Email transmission cannot be guaranteed to be secure or error-free. Jump Trading, therefore, does not make any guarantees as to the completeness or accuracy of this email or any attachments. This email is for informational purposes only and does not constitute a recommendation, offer, request or solicitation of any kind to buy, sell, subscribe, redeem or perform any type of transaction of a financial product. > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > From lgautier at gmail.com Sat Nov 29 15:35:21 2008 From: lgautier at gmail.com (Laurent Gautier) Date: Sat, 29 Nov 2008 15:35:21 +0100 Subject: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5 Message-ID: <49315329.7050703@gmail.com> Dear List, I am having a problem triggered by having R-2.8 (R version 2.8.0 Patched (2008-11-15 r46953)) installed on Mac OS X 10.5. The steps needed to generate the error are: - install a binary distribution of R (default location) - add R to the PATH - install the python module pycairo (http://www.cairographics.org/releases/pycairo-1.4.12.tar.gz) That last step results in an error, and the error message point in the direction of the R installation (see below): Making install in cairo test -z "/sw/lib/python2.5/site-packages/cairo" || .././install-sh -c -d "/sw/lib/python2.5/site-packages/cairo" /bin/sh ../libtool --mode=install /Library/Frameworks/R.framework/Resources/bin/install -c '_cairo.la' '/sw/lib/python2.5/site-packages/cairo/_cairo.la' /Library/Frameworks/R.framework/Resources/bin/install -c .libs/_cairo.so /sw/lib/python2.5/site-packages/cairo/_cairo.so /Library/Frameworks/R.framework/Resources/bin/install: line 113: /sh/dcf.sh: No such file or directory make[2]: *** [install-pycairoexecLTLIBRARIES] Error 1 make[1]: *** [install-am] Error 2 make: *** [install-recursive] Error 1 Editing /Library/Frameworks/R.framework/Resources/bin/install, and hard-code the right path to R_SHARE_DIR is obviously an option, but I would like to hear that something more elegant is possible. Laurent From maechler at stat.math.ethz.ch Sat Nov 29 18:10:08 2008 From: maechler at stat.math.ethz.ch (maechler at stat.math.ethz.ch) Date: Sat, 29 Nov 2008 18:10:08 +0100 (CET) Subject: [Rd] A small bug in R code of the legend function of the Graphics pacakge (PR#13340) Message-ID: <20081129171008.C54A0282EFF0@mail.pubhealth.ku.dk> >>>>> "ASh" == asherman >>>>> on Thu, 27 Nov 2008 14:30:04 +0100 (CET) writes: ASh> Full_Name: Arkady Sherman ASh> Version: 2.8.0 ASh> OS: Windows XP ASh> Submission from: (NULL) (158.195.16.114) ASh> Please consider initialization of the "seg.len" ASh> variable. It's done only ASh> if (do.lines) { seg.len <- 2 .., ASh> but after the seg.len is used: ASh> if (has.pch) { ASh> pch <- rep(pch, length.out = n.leg) ASh> pt.bg <- rep(pt.bg, length.out = n.leg) ASh> pt.cex <- rep(pt.cex, length.out = n.leg) ASh> pt.lwd <- rep(pt.lwd, length.out = n.leg) ASh> ok <- !is.na(pch) & (is.character(pch) | pch >= 0) ASh> x1 <- (if (merge) ASh> xt - (seg.len/2) * xchar ASh> so if do.lines isn't specified, but has.pch and merge are specified an error is ASh> produced. but do.lines is never specified. It can be FALSE (if there are no lines drawn) and a user can indeed set 'merge = TRUE" in such a situation. However, can you think of a situation where this was desirable? I think it should not have any effect in such a case {... but unfortunately it currently has ... yet another sign that legend() is ``hopelessly over-featured'' ;-) } and possibly rather give a warning in such a case... ASh> Guess that seg.len should be initialized before the condition "if (do.lines)" not really; it means 'segment length' should not be used unless segments ("lines") are drawn. Thank you for your note; you are right that legend() is not entirely correct in such a border-line situation. Regards, Martin Maechler, ETH Zurich From stefan.evert at uos.de Sun Nov 30 13:51:40 2008 From: stefan.evert at uos.de (Stefan Evert) Date: Sun, 30 Nov 2008 13:51:40 +0100 Subject: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5 In-Reply-To: <49315329.7050703@gmail.com> References: <49315329.7050703@gmail.com> Message-ID: <5EF06ADB-867B-4151-BBD2-E8293BE42745@uos.de> > The steps needed to generate the error are: > > - install a binary distribution of R (default location) > - add R to the PATH Did you actually add /Library/Frameworks/R.framework/Resources/bin/ to your PATH? You're not supposed to do that! What made you think so? This directory contains a range of support scripts for R which are not intended for direct use from the command line or other programs. In my installation, there's just a symlink from /usr/bin/R to the R binary in the directory above, which AFAIK is the only program you need to invoke directly. In your case, R's "INSTALL" script, which implements the "R CMD INSTALL" functionality masks the standard "install" program in /usr/ bin/install, so Python's installer now picks up a completely wrong program. Even if you edit R's "INSTALL" script, it'll do something entirely different from what you expect. BTW, putting the R binary directory ahead of system directories such as /usr/bin in your PATH is an even worse idea than including it there in the first place. ;-) Best regards, Stefan Evert [ stefan.evert at uos.de | http://purl.org/stefan.evert ] From armstrong.whit at gmail.com Sun Nov 30 16:25:38 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Sun, 30 Nov 2008 10:25:38 -0500 Subject: [Rd] parallel build for package? (equivalent of make -j8) Message-ID: <8ec76080811300725v1021f0b2l987da0db33c2f961@mail.gmail.com> I have a package that takes about 20 minutes to compile which tends to prolong the compile/test/compile cycle. Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? I looked at R CMD INSTALL --help, but I don't see anything obvious arguments to do this. Thanks, Whit From p.dalgaard at biostat.ku.dk Sun Nov 30 18:29:46 2008 From: p.dalgaard at biostat.ku.dk (Peter Dalgaard) Date: Sun, 30 Nov 2008 18:29:46 +0100 Subject: [Rd] parallel build for package? (equivalent of make -j8) In-Reply-To: <8ec76080811300725v1021f0b2l987da0db33c2f961@mail.gmail.com> References: <8ec76080811300725v1021f0b2l987da0db33c2f961@mail.gmail.com> Message-ID: <4932CD8A.6000402@biostat.ku.dk> Whit Armstrong wrote: > I have a package that takes about 20 minutes to compile which tends to > prolong the compile/test/compile cycle. > > Does anyone know how to get R CMD check or R CMD INSTALL to use parallel make? > > I looked at R CMD INSTALL --help, but I don't see anything obvious > arguments to do this. Platform? Does MAKE="make -j8" R CMD INSTALL ... not work? (Beware: Here there be Tygers. Parallel makes have their surprises....) -- O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 From armstrong.whit at gmail.com Sun Nov 30 19:30:56 2008 From: armstrong.whit at gmail.com (Whit Armstrong) Date: Sun, 30 Nov 2008 13:30:56 -0500 Subject: [Rd] parallel build for package? (equivalent of make -j8) In-Reply-To: <4932CD8A.6000402@biostat.ku.dk> References: <8ec76080811300725v1021f0b2l987da0db33c2f961@mail.gmail.com> <4932CD8A.6000402@biostat.ku.dk> Message-ID: <8ec76080811301030o62d88b95h8233ecd5499a46db@mail.gmail.com> linux, x86-64. omg, MAKE="make -j8" R CMD INSTALL works beautifully. Thanks for making me see the light. Cheers, Whit On Sun, Nov 30, 2008 at 12:29 PM, Peter Dalgaard wrote: > Whit Armstrong wrote: >> >> I have a package that takes about 20 minutes to compile which tends to >> prolong the compile/test/compile cycle. >> >> Does anyone know how to get R CMD check or R CMD INSTALL to use parallel >> make? >> >> I looked at R CMD INSTALL --help, but I don't see anything obvious >> arguments to do this. > > Platform? > > Does > > MAKE="make -j8" R CMD INSTALL ... > > not work? > > (Beware: Here there be Tygers. Parallel makes have their surprises....) > > -- > O__ ---- Peter Dalgaard ?ster Farimagsgade 5, Entr.B > c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K > (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 > ~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk) FAX: (+45) 35327907 > From spencer.graves at pdf.com Sun Nov 30 22:36:14 2008 From: spencer.graves at pdf.com (Spencer Graves) Date: Sun, 30 Nov 2008 13:36:14 -0800 Subject: [Rd] normal-bracket50bracket-normal? Message-ID: <4933074E.9020708@pdf.com> Hello: I've found structures like "normal-bracket50bracket-normal" in help files for R packages including the following: * "mergeprepare" and "mergematrices" in a document dated March 3, 2004 by Richard Mott; the second contains "normal-bracket30bracket-normal". * "Fperm.fd" and "tperm.fd" in the "fda" package; these help pages were written primarily by Giles Hooker. * "compareDerivatives" in the "maxLik" package; this help page was written by Ott Toomet and me. What can we do to eliminate this nonsense comment? Constructs like this seem to be generated in perl code used in "R CMD" processing (https://svn.r-project.org/R/trunk/share/perl/R/Rdconv.pm). Thanks, Spencer Graves From bolker at ufl.edu Sun Nov 30 23:11:10 2008 From: bolker at ufl.edu (Ben Bolker) Date: Sun, 30 Nov 2008 17:11:10 -0500 Subject: [Rd] methods not found inside function? Message-ID: <49330F7E.2000408@ufl.edu> I am currently attempting to hack the recently featured profileModels package so that it can handle models generated by the lme4 (mixed models) package. I'm getting really confused by different behavior of summary() before and after loading the lme4 package, and inside and outside the profileMethod() function. The basic behavior is that with lme4 loaded, and "obj" a fitted object of class "mer" from this package, summary(obj) calls the S4 method. However, as soon as I step into the profileMethod() function from the profileMethod package, summary() on a copy of the same object that has been passed to the function no longer calls the S4 method ... Any explanations/workarounds for this ... ? cheers Ben Bolker ## before loading the lme4 package: > summary function (object, ...) UseMethod("summary") ## now load lme4: library(lme4) gm1 <- glmer(cbind(incidence, size - incidence) ~ period + (1 | herd), family = binomial, data = cbpp) ## examine "summary": > summary standardGeneric for "summary" defined from package "base" function (object, ...) standardGeneric("summary") Methods may be defined for arguments: object Use showMethods("summary") for currently available ones. summary(gm1) ## Generalized linear mixed model fit by the Laplace approximation ## Formula: cbind(incidence, size - incidence) ~ period + (1 | herd) ## Data: cbpp ## etc ... library(profileModel) debug(profileModel) prof1.gm1 <- profileModel(fitted=gm1, objective=deviance) ## step into the function, and then try: Browse[1]> summary function (object, ...) UseMethod("summary") Browse[1]> summary(gm1) Length Class Mode 1 mer S4 -- Ben Bolker Associate professor, Biology Dep't, Univ. of Florida bolker at ufl.edu / www.zoology.ufl.edu/bolker GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc From lgautier at gmail.com Sun Nov 30 23:11:46 2008 From: lgautier at gmail.com (Laurent Gautier) Date: Sun, 30 Nov 2008 23:11:46 +0100 Subject: [Rd] unrelated software install triggering an error from R's install script on Mac OS X 10.5 In-Reply-To: <5EF06ADB-867B-4151-BBD2-E8293BE42745@uos.de> References: <49315329.7050703@gmail.com> <5EF06ADB-867B-4151-BBD2-E8293BE42745@uos.de> Message-ID: <49330FA2.1030604@gmail.com> Stefan Evert wrote: > >> The steps needed to generate the error are: >> >> - install a binary distribution of R (default location) >> - add R to the PATH > > Did you actually add > > /Library/Frameworks/R.framework/Resources/bin/ > > to your PATH? You're not supposed to do that! What made you think so? Coming from an UNIX background, adding a directory like bin/ to the PATH does not appear unreasonable. > This directory contains a range of support scripts for R which are not > intended for direct use from the command line or other programs. In my > installation, there's just a symlink from /usr/bin/R to the R binary in > the directory above, which AFAIK is the only program you need to invoke > directly. I am relatively new to OS X, so I cannot tell whether this is an R specificity, or the way things are usually done on OS X are somewhat very different from the UNIX way. I am surprised by this cherry pick one executable in bin/ / don't touch the PATH. > In your case, R's "INSTALL" script, which implements the "R CMD INSTALL" > functionality masks the standard "install" program in /usr/bin/install, > so Python's installer now picks up a completely wrong program. Even if > you edit R's "INSTALL" script, it'll do something entirely different > from what you expect. To my great dismay I am hearing here that Mac OS X is not case-sensitive. > BTW, putting the R binary directory ahead of system directories such as > /usr/bin in your PATH is an even worse idea than including it there in > the first place. ;-) I am used to the fact that adding a bin/ directory in the PATH (and *ahead* of all other components in the PATH) is the way to add custom binaries. I cannot exclude that I am missing some specificities of Mac OS X, but that idea seems to be at least shared by the fink project (their default install puts /sw/bin ahead of all the rest). I suppose that there is a documentation for R-on-OS-X and that I overlooked it. Laurent > > > Best regards, > Stefan Evert > > [ stefan.evert at uos.de | http://purl.org/stefan.evert ] > > > From Arkady.Sherman at ksu.ru Sat Nov 29 20:05:15 2008 From: Arkady.Sherman at ksu.ru (Arkady.Sherman at ksu.ru) Date: Sat, 29 Nov 2008 20:05:15 +0100 (CET) Subject: [Rd] A small bug in R code of the legend function of the Graphics (PR#13350) Message-ID: <20081129190515.AD784282EFF0@mail.pubhealth.ku.dk> Martin Maechler wrote: > but do.lines is never specified. It can be FALSE (if there are no > lines drawn) and a user can indeed set 'merge = TRUE" in such a > situation. > However, can you think of a situation where this was desirable? > I think it should not have any effect in such a case > {... but unfortunately it currently has ... yet another > sign that legend() is ``hopelessly over-featured'' ;-) } > and possibly rather give a warning in such a case... > > > ASh> Guess that seg.len should be initialized before the condition "if (do.lines)" > > not really; it means 'segment length' should not be used unless > segments ("lines") are drawn. > > Thank you for your note; you are right that legend() is not > entirely correct in such a border-line situation. > > Regards, > Martin Maechler, ETH Zurich Thanks for the response. Yes it's unusual to set merge without lines. I modified existing code and didn't pay attention to the merge parameter and got the error "object "seg.len" not found". There was no connection between the merge parameter and the error produced. So I modified the code and didn't unset merge :). So it's better to gave an warning, or to set automatically merge to false if isn't needed. Arkady