[Rd] chron on windows (PR#8130)

Full_Name: Dragan Sestovic Version: 2.0.1 OS: windows XP Submission from: (NULL) (216.80.117.146) Function dates() does not work correctly on the windows system for years after 2000. On unix system it is OK. Here are the examples I got on my R 2.0.1. on Windows XP: > dates("02/10/2002") [1] 02/1

Re: [Rd] chron on windows (PR#8130)

[EMAIL PROTECTED] wrote: > Full_Name: Dragan Sestovic > Version: 2.0.1 > OS: windows XP > Submission from: (NULL) (216.80.117.146) > > > Function dates() does not work correctly on the windows system for years after > 2000. On unix system it is OK. Here are the examples I got on my R 2.0.1. on >

Re: [Rd] A question on R memory management in .Fortran() calls under Windows

Dear Duncan and Simon, many thanks for your helpful reply. > Duncan Murdoch wrote: > It looks as though your Fortran compiler is allocating the new matrix on > the stack. R doesn't give you a huge stack, and that's causing the > overflow. When you get R to do the allocation, it does it on the h

Re: [Rd] A question on R memory management in .Fortran() calls under Windows

Simone Giannerini wrote: > Dear Duncan and Simon, > > many thanks for your helpful reply. > > >>Duncan Murdoch wrote: >>It looks as though your Fortran compiler is allocating the new matrix on >>the stack. R doesn't give you a huge stack, and that's causing the >>overflow. When you get R to do

Re: [Rd] A question on R memory management in .Fortran() calls under Windows

Simone, On Sep 12, 2005, at 4:30 AM, Simone Giannerini wrote: > yes, CVF allocates automatic objects on the stack and apparently > there is no way of changing it. Yes, that's bad news. > By the way, increasing the stack of the fortran process when > linking does not solve the problem In ge

Re: [Rd] A question on R memory management in .Fortran() calls under Windows

> I think it's far from the best optimizing compiler, but the Fortran that > comes with MinGW (g77 currently in Windows) is the one used to build R, > so it's the one that will is most likely to work with it without > fiddling. But I don't use Fortran, so I don't know what else is available. > >

Re: [Rd] A question on R memory management in .Fortran() calls under Windows

On 9/12/05, Simon Urbanek <[EMAIL PROTECTED]> wrote: > Simone, > > On Sep 12, 2005, at 4:30 AM, Simone Giannerini wrote: > > > yes, CVF allocates automatic objects on the stack and apparently > > there is no way of changing it. > > Yes, that's bad news. > > > By the way, increasing the stack of

[Rd] contributed Windows binary packages for R-2.2.0 alpha

Dear package developers, contributed Windows binary packages for R-devel are available for some time now and should have propagated through CRAN. I have re-compiled and re-checked all packages under R-2.2.0 alpha again today. Results will propagate through CRAN within a couple of days (on CRAN

[Rd] ptr_R_EditFile, R_WriteConsole, and R_ShowMessage

Hi! I have an application embedding R. For that of course, it is great, that since R 2.1.0 the pointers in Rinterface.h allow me to override some callbacks, easily. However, after implementing/overriding a couple of those, I'm a bit confused about when exactly they get called. So, here are a fe

Re: [Rd] ptr_R_EditFile, R_WriteConsole, and R_ShowMessage

> R_ShowMessage (ptr_R_ShowMessage): > This one, too, seems to have very few use-cases (but at least some). Most > seem to be for errors during startup. > I wonder: > 1) If this callback is most useful during startR (...), can it even be used > in a meaningful way? After all, startR () also initial

[Rd] R news: Call for Papers

Dear useRs and developeRs, the next issue of `R news' is scheduled for the beginning of November and we are now accepting submissions for this last issue in 2005. For more information see http://cran.r-project.org/doc/Rnews/ If you are the author of a package on CRAN and you would like t