Re: [Rd] R-bugs e-mail problems {was "sapply(Date, is.numeric)"}
> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> > on Tue, 29 Jul 2008 15:40:37 -0400 writes: RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, RobMcG> once by email (below), and the second time 5 days later directly to the RobMcG> bugs.r-project.org website. As far as I can tell, the bug tracking RobMcG> system hasn't picked this up. Also it looks like the latest "incoming" RobMcG> bug is dated 25 May 2008, so perhaps others are having difficulty as RobMcG> well. (cc: r-bugs) Well, if you look into the *trashcan*, you find the latest ones to be from 'July 4' , (and it may well have been who cleaned up the incoming mess, moving 95% of the messages to the trashcan); so the mail-interface seemed to have stopped at the US national holiday. Given how ineffective our spam filters have become there, it may not be a big harm :-) There have plans for a long time to change to a new bug report system (probably with*out* e-mail interface - alas!), but there have been diverse reasons why this has never happened. One of the reasons: We'd want to migrate the current repository (all the "bug - fix threads", apart from the trashcan) to the new system, and I think haven't found anyone to do that for us. We had even considered the R foundation would offer a monetary amount to someone (smart programmer) to program the one-time migration, but that somehow failed, too? I'm getting really off-topic, but this my be worthwhile theme to open just before meeting many at the useR!2008 in Dortmund. Martin Maechler, ETH Zurich and R-Core __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric)
> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> > on Tue, 29 Jul 2008 15:40:37 -0400 writes: RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, [... r-bugs problems discussed in a separate thread ] RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> x <- data.frame(dt=Sys.Date()) >> is.numeric(x$dt) RobMcG> [1] FALSE >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE RobMcG> ## Yet, sapply seems aware of the Date class >> sapply(x, class) RobMcG> dt RobMcG> "Date" Yes, thanks a lot, Robert, for the report. That *is* a bug somewhere in the .Internal(lapply(...)) C code, when S3 dispatch of primitive functions should happen. Here's an R scriptlet exposing a 2nd example ### lapply(list, FUN) ### -- seems to sometimes fail for ### .Primitive S3-generic functions (ds <- seq(from=Sys.Date(), by=1, length=4)) ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ll <- list(d=ds) lapply(list(d=ds), round) ## -> Error in lapply(list(d = ds), round) : dispatch error ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: sapply(list(d=ds), is.numeric) ## TRUE ## in spite of is.numeric(`[[`(ll,1)) ## FALSE , because of is.numeric.date ## or round(`[[`(ll,1)) ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ##- But I'm currently too much tied up with other duties, to find and test bug-fix. Martin Maechler, ETH Zurich and R-Core Team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric)
Try this workaround
sapply(x, function(x) is.numeric(x))
dt
FALSE
is.numeric is primitive, and primitive functions don't always play well
with [sl]apply.
On Tue, 29 Jul 2008, McGehee, Robert wrote:
FYI,
I've tried posting the below message twice to the bug tracking system,
once by email (below), and the second time 5 days later directly to the
bugs.r-project.org website. As far as I can tell, the bug tracking
system hasn't picked this up. Also it looks like the latest "incoming"
bug is dated 25 May 2008, so perhaps others are having difficulty as
well. (cc: r-bugs)
Cheers, Robert
-Original Message-
From: McGehee, Robert
Sent: Monday, July 14, 2008 9:51 AM
To: [EMAIL PROTECTED]
Subject: sapply(Date, is.numeric)
R-developers,
The results below are inconsistent. From the documentation for
is.numeric, I expect FALSE in both cases.
x <- data.frame(dt=Sys.Date())
is.numeric(x$dt)
[1] FALSE
sapply(x, is.numeric)
dt
TRUE
## Yet, sapply seems aware of the Date class
sapply(x, class)
dt
"Date"
platform i386-pc-mingw32
arch i386
os mingw32
system i386, mingw32
status
major 2
minor 7.0
year 2008
month 04
day22
svn rev45424
language R
version.string R version 2.7.0 (2008-04-22)
Thanks,
Robert McGehee, CFA
Geode Capital Management, LLC
One Post Office Square, 28th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
This e-mail, and any attachments hereto, are intended fo...{{dropped:12}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric)
On Wed, 30 Jul 2008, Martin Maechler wrote: "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> on Tue, 29 Jul 2008 15:40:37 -0400 writes: RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, [... r-bugs problems discussed in a separate thread ] RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> x <- data.frame(dt=Sys.Date()) >> is.numeric(x$dt) RobMcG> [1] FALSE >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE RobMcG> ## Yet, sapply seems aware of the Date class >> sapply(x, class) RobMcG> dt RobMcG> "Date" Yes, thanks a lot, Robert, for the report. That *is* a bug somewhere in the .Internal(lapply(...)) C code, when S3 dispatch of primitive functions should happen. The bug is in do_is, which uses CHAR(PRINTNAME(CAR(call))), and when called from lapply that gives "FUN" not "is.numeric". The root cause is the following comment FUN = CADR(args); /* must be unevaluated for use in e.g. bquote */ and hence that the function in the *call* passed to do_is can be unevaluated. Here's an R scriptlet exposing a 2nd example ### lapply(list, FUN) ### -- seems to sometimes fail for ### .Primitive S3-generic functions (ds <- seq(from=Sys.Date(), by=1, length=4)) ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ll <- list(d=ds) lapply(list(d=ds), round) ## -> Error in lapply(list(d = ds), round) : dispatch error And that's a separate issue, in DispatchGroup which states that arguments have been evaluated (true) but the 'call' from lapply gives the unevaluated arguments and so there is a mismatch. I'm testing fixes for both. ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: sapply(list(d=ds), is.numeric) ## TRUE ## in spite of is.numeric(`[[`(ll,1)) ## FALSE , because of is.numeric.date ## or round(`[[`(ll,1)) ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" ##- But I'm currently too much tied up with other duties, to find and test bug-fix. Martin Maechler, ETH Zurich and R-Core Team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sapply(Date, is.numeric)
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]> > on Wed, 30 Jul 2008 13:29:38 +0100 (BST) writes: BDR> On Wed, 30 Jul 2008, Martin Maechler wrote: >>> "RobMcG" == McGehee, Robert <[EMAIL PROTECTED]> >>> on Tue, 29 Jul 2008 15:40:37 -0400 writes: >> RobMcG> FYI, RobMcG> I've tried posting the below message twice to the bug tracking system, >> >> [... r-bugs problems discussed in a separate thread ] >> >> >> RobMcG> R-developers, RobMcG> The results below are inconsistent. From the documentation for RobMcG> is.numeric, I expect FALSE in both cases. >> >> >> x <- data.frame(dt=Sys.Date()) >> >> is.numeric(x$dt) RobMcG> [1] FALSE >> >> sapply(x, is.numeric) RobMcG> dt RobMcG> TRUE >> RobMcG> ## Yet, sapply seems aware of the Date class >> >> sapply(x, class) RobMcG> dt RobMcG> "Date" >> >> Yes, thanks a lot, Robert, for the report. >> >> That *is* a bug somewhere in the .Internal(lapply(...)) C code, >> when S3 dispatch of primitive functions should happen. BDR> The bug is in do_is, which uses CHAR(PRINTNAME(CAR(call))), and when BDR> called from lapply that gives "FUN" not "is.numeric". The root cause is BDR> the following comment BDR> FUN = CADR(args); /* must be unevaluated for use in e.g. bquote */ BDR> and hence that the function in the *call* passed to do_is can be BDR> unevaluated. aah! I see. >> Here's an R scriptlet exposing a 2nd example >> >> ### lapply(list, FUN) >> ### -- seems to sometimes fail for >> ### .Primitive S3-generic functions >> >> (ds <- seq(from=Sys.Date(), by=1, length=4)) >> ##[1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> ll <- list(d=ds) >> lapply(list(d=ds), round) >> ## -> Error in lapply(list(d = ds), round) : dispatch error BDR> And that's a separate issue, in DispatchGroup which states that arguments BDR> have been evaluated (true) but the 'call' from lapply gives the BDR> unevaluated arguments and so there is a mismatch. yes, I too found that this was a separate issue, the latter one being new since version 2.7.0 BDR> I'm testing fixes for both. Excellent! Martin >> ## or -- related to bug report by Robert McGehee on R-devel, on 2008-07-29: >> sapply(list(d=ds), is.numeric) >> ## TRUE >> >> ## in spite of >> is.numeric(`[[`(ll,1)) ## FALSE , because of >> is.numeric.date >> >> ## or >> round(`[[`(ll,1)) >> ## [1] "2008-07-30" "2008-07-31" "2008-08-01" "2008-08-02" >> >> ##- >> >> But I'm currently too much tied up with other duties, >> to find and test bug-fix. >> >> Martin Maechler, ETH Zurich and R-Core Team __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] closing View windows after multiple View(x) crashes
I'm using Gnome. Ben Prof Brian Ripley wrote: We have found elsewhere that the need to use XSync is very dependent on the window manager. What manager were you using? I'll add the call in any case. On Tue, 29 Jul 2008, Bill Dunlap wrote: On Tue, 29 Jul 2008, Ben Bolker wrote: That works like a charm. Thanks! Ben Bolker Good. Here is the patch I used. (I didn't send it earlier because my code still had a bunch of Rprintf calls in it to track the event loop activity. Index: src/modules/X11/dataentry.c === --- src/modules/X11/dataentry.c(revision 46139) +++ src/modules/X11/dataentry.c(working copy) @@ -1881,6 +1881,7 @@ #endif XDestroyWindow(iodisplay, DE->iowindow); /* XCloseDisplay(iodisplay); */ +Rsync(DE); } #define USE_Xt 1 Valgrind reports a slew of memory leaks when R closes after using View(), but it didn't show any use of freed or uninitialized memory after that change. Bill Dunlap Insightful Corporation bill at insightful dot com "All statements in this message represent the opinions of the author and do not necessarily reflect Insightful Corporation policy or position." __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R, Macports and C++ streams
Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Cheers, Ernest Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 15:18, Kjell Konis wrote: I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. The doc warns that the output to stdout using iostreams may not appear on the console, there is no indication that doing this may crash R (and this has never happened to me before). Certainly, the use of file streams (fstreams) should work just fine. Ernest Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On Jul 30, 2008, at 12:35 , Ernest Turro wrote: On 30 Jul 2008, at 15:18, Kjell Konis wrote: I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. The doc warns that the output to stdout using iostreams may not appear on the console, there is no indication that doing this may crash R (and this has never happened to me before). Certainly, the use of file streams (fstreams) should work just fine. FWIW I saw this problem when using mismatching compilers before (long time ago when we had to use FSF-built gcc because of bugs in Apple's gcc). Its likely cause is a combination of incompatible ABIs and libstdc++ mismatch. Note that Apple's gcc build script goes into great pains to not mess up system stdc++ because it's asking for trouble. Cheers, Simon Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Although it should be possible to build R with non- Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple-supplied gcc 4.2 instead of 4.0 ? Thanks, Ernest Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 17:58, Simon Urbanek wrote: On Jul 30, 2008, at 12:35 , Ernest Turro wrote: On 30 Jul 2008, at 15:18, Kjell Konis wrote: I found this in Writing R Extensions: "Using C++ iostreams, as in this example, is best avoided. There is no guarantee that the output will appear in the R console, and indeed it will not on the R for Windows console. Use R code or the C entry points (see Printing) for all I/O if at all possible." That is, use Rprintf() instead. The fact that your code works with one version of gcc and not another can probably be chalked up to coincidence. The doc warns that the output to stdout using iostreams may not appear on the console, there is no indication that doing this may crash R (and this has never happened to me before). Certainly, the use of file streams (fstreams) should work just fine. FWIW I saw this problem when using mismatching compilers before (long time ago when we had to use FSF-built gcc because of bugs in Apple's gcc). Its likely cause is a combination of incompatible ABIs and libstdc++ mismatch. Note that Apple's gcc build script goes into great pains to not mess up system stdc++ because it's asking for trouble. Yes, this sounds like the most likely culprit. I guess, ultimately, Macports GCC maintainers should make sure their build script goes through the same hoops as Apple's to avoid this kind of mismatch problem with libstdc++. The best thing would be for the R port to depend on Apple-supplied gcc rather than the Macports gcc. Cheers Ernest Cheers, Simon Kjell On Jul 30, 2008, at 3:45 PM, Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Thanks, Ernest __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple- supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non- Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 19:23, Simon Urbanek wrote: On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple- supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only Thanks. I just realised that what was causing compilation to fail was the inclusion of the "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" flag. So now I have a package that compiles fine I think on most systems (I use the AC_OPENMP macro to check for openmp support, which it will generally not find on a Mac). Leopard users wishing to use openmp must: 1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1) 2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf (or create appropriate symlinks) 3) remove all instances of "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" in Makeconf I have found this to work on my system. But is this the easiest solution for Mac users wishing to use openmp in the package - or can you think of a way of avoiding 3) ? Thanks for your help, Ernest As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non- Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R, Macports and C++ streams
On 30 Jul 2008, at 20:25, Simon Urbanek wrote: On Jul 30, 2008, at 15:13 , Ernest Turro wrote: On 30 Jul 2008, at 19:23, Simon Urbanek wrote: On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple-supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only Thanks. I just realised that what was causing compilation to fail was the inclusion of the "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" flag. Yes, as I told you. So now I have a package that compiles fine I think on most systems (I use the AC_OPENMP macro to check for openmp support, which it will generally not find on a Mac). Leopard users wishing to use openmp must: 1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1) 2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf (or create appropriate symlinks) 3) remove all instances of "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" in Makeconf I have found this to work on my system. But is this the easiest solution for Mac users wishing to use openmp in the package - or can you think of a way of avoiding 3) ? The easiest solution is 2) in my previous e-mail (it uses gcc-4.2 by default and targets Leopard) and that's what you're forcing with your patches anyway. Could you please clarify how you go about building packages for Leopard-only without using my patches? Thanks, Ernest Cheers, Simon As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about Ma
Re: [Rd] R, Macports and C++ streams
On Jul 30, 2008, at 15:13 , Ernest Turro wrote: On 30 Jul 2008, at 19:23, Simon Urbanek wrote: On Jul 30, 2008, at 13:16 , Ernest Turro wrote: On 30 Jul 2008, at 18:04, Simon Urbanek wrote: On Jul 30, 2008, at 12:32 , Ernest Turro wrote: On 30 Jul 2008, at 15:46, Simon Urbanek wrote: On Jul 30, 2008, at 9:45 , Ernest Turro wrote: Dear all, R on Macports relies on GCC 4.3 to build packages. I find that packages with shared objects that use C++ streams crash R if they're compiled using Macports' gcc43, but work fine if compiled in exactly the same way using Apple-supplied GCC 4.2. Has anyone here had the same issue/know what is causing this problem? Using compilers from MacPorts and similar suites (Darwin ports, Fink etc.) is strongly discouraged (and outright not supported by the CRAN binary) since they have been known to be badly broken in the past and when whenever tested so far they were incomplete and incompatible. You have to re-compile R yourself with those tools (and you're entirely on your own) if you really want to use them. CRAN binaries work only with Apple's gcc branches, if you want to use anything else, you have to follow the unix R instructions and compile everything from sources. Dear Kjell, As you can see above, your R port on Macports appears to be broken and has a reputation of having been broken for a while. I for one have experienced odd problems as described above. To avoid further issues with unsuspecting Macports users, perhaps it would be good to pull the port from the repository until a decent level of reliability can be provided ? Although I do agree on your last point, I just want to clarify that I was talking about supported R for Mac setup (as provided in binary form on CRAN). Having installed the R binary for Mac, I've noticed that it uses Apple's default gcc 4.0.1. That is not exactly true - it uses whatever your gcc version is. You can use Apple's gcc 4.0 or 4.2, they both work. The problem with this is that there is no OpenMP support in gcc until version 4.2, which is available as a preview from apple on ADC. FYI it's part of Xcode 3.1 ... Changing gcc and g++ to gcc-4.2 and g++-4.2 in the default Makeconf isn't quite enough, as R also needs to look in the appropriate header paths, etc...(e.g. to find omp.h). Could you recommend an easy way of getting a binary R installation to work with apple-supplied gcc 4.2 instead of 4.0 ? I suspect you're confusing several separate issues here - the include paths for OMP have nothing to do with R, they are part of the gcc and as such added regardless of the include flags. Just try gcc-4.2 omp.c -o omp -fopenmp which specifies no include flags and works just fine. The real issue here is that Apple doesn't provide gcc-4.2 support for Tiger, so you cannot use 10.4 SDK unless you also install the corresponding libraries. Hence you have two choices: 1) install gcc-4.2 libraries in 10.4u SDK or 2) build for Leopard-only Thanks. I just realised that what was causing compilation to fail was the inclusion of the "-isysroot /Developer/SDKs/MacOSX10.4u.sdk" flag. Yes, as I told you. So now I have a package that compiles fine I think on most systems (I use the AC_OPENMP macro to check for openmp support, which it will generally not find on a Mac). Leopard users wishing to use openmp must: 1) install apple-supplied gcc 4.2 (e.g. via Xcode 3.1) 2) replace gcc and g++ by gcc-4.2 and g++4.2 respectively in Makeconf (or create appropriate symlinks) 3) remove all instances of "-isysroot /Developer/SDKs/ MacOSX10.4u.sdk" in Makeconf I have found this to work on my system. But is this the easiest solution for Mac users wishing to use openmp in the package - or can you think of a way of avoiding 3) ? The easiest solution is 2) in my previous e-mail (it uses gcc-4.2 by default and targets Leopard) and that's what you're forcing with your patches anyway. Cheers, Simon As for 1) you can get just the SDK files for Tiger from http://r.research.att.com/tools/ (you'll need to symlink darwin8 directory to darwin9) As for 2) you can use the Leopard binaries from http://r.research.att.com/ Cheers, Simon Although it should be possible to build R with non-Apple gcc, but it must be done very carefully, because there are many dangers lurking in the interaction of system libraries with those from non-Apple tools. This has nothing to do with R, it's about knowledge how things work in OS X and it is very important when compilers are involved [unfortunately there are many binaries around from people that don't understand the intricacies of OS X well enough and think it's almost like a Linux box - I'm not talking about MacPorts in particular, it's just a general observation]. Cheers, Simon __ R-devel@r-project.org mailing list https://
[Rd] Name clashes among packages
To handle name clashes among packages I wonder if we could have a namespace setting between exported and not-exported which is exported but you have to use :: (two dots) to access its objects. The difference between mandatory two dot and three dots in this case is that the exported objects are intended to be accessed whereas the three dot ones are not and it may be important to retain that distinction even though you have to explicitly preface both. If the package uses this intermediate form of exporting then it could be guaranteed that there are no name clashes. Perhaps it should be possible to specify this on an object by object basis within the package. This could be useful for larger projects made up of many packages. Of course one can already just have the convention that one uses two dots to access package objects but this would enforce it for certain packages and allow those package to avoid the annoying name clash warnings when loaded. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
