[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/10/92
> dates("02/10/2003")
[1] 02/09/93
> dates("02/10/2010")
[1] 02/10/00
>
Regards
Dragan Sestovic
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
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
> Windows XP:
>
>
>>dates("02/10/2002")
>
> [1] 02/10/92
Please upgrade both R and chron. It works perfectly with recent versions.
Please read the FAQs and learn to check against recent versions of R (at
least released version, these days in particular the alpha versions of R!)
Uwe Ligges
>>dates("02/10/2003")
>
> [1] 02/09/93
>
>>dates("02/10/2010")
>
> [1] 02/10/00
>
>
>
> Regards
>
> Dragan Sestovic
>
> __
> 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] 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 heap, > which has no artificial limits. Only a pointer to the object ends up on > the stack. yes, CVF allocates automatic objects on the stack and apparently there is no way of changing it. By the way, increasing the stack of the fortran process when linking does not solve the problem > I'd say your only reasonable workarounds are to tell your compiler to > use the heap for the local matrix allocation (if that's possible), or do > your allocations in R. I might follow the second way, in any case, I am considering switching to Linux, I have also considered changing compiler under Win, any suggestions on the choice would be welcomed. Many thanks again, kind regards, Simone Giannerini __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 the allocation, it does it on the heap, >>which has no artificial limits. Only a pointer to the object ends up on >>the stack. > > > yes, CVF allocates automatic objects on the stack and apparently there > is no way of changing it. By the way, increasing the stack of the > fortran process when linking does not solve the problem > > >>I'd say your only reasonable workarounds are to tell your compiler to >>use the heap for the local matrix allocation (if that's possible), or do >>your allocations in R. > > > I might follow the second way, in any case, I am considering switching > to Linux, I have also considered changing compiler under Win, any > suggestions on the choice would be welcomed. 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. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 general the stack size is also governed by the system limits so you may need to increase those as well, but still, that won't really solve your problem. >> I'd say your only reasonable workarounds are to tell your compiler to >> use the heap for the local matrix allocation (if that's possible), >> or do >> your allocations in R. >> > > I might follow the second way, in any case, I am considering > switching to Linux, I have also considered changing compiler under > Win, any suggestions on the choice would be welcomed. As Duncan was mentioning g77 is your friend if you can convert your code to f77. If you don't have that option, you're partially on your own. GNU Fortran 95 (gfortran) may be an option as it exists both for unix and Windows (although not as a part of MinGW), but R currently doesn't provide .f90 target so you'll need to add your own small Makevars. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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. > > Duncan Murdoch > Thanks a lot anyway, in a comparative review I've come through recently (http://www.polyhedron.co.uk/compare.html) the Salford compiler seems to be one of the most protected against errors but also one of the slowest. Intel compiler seems to be one of the fastest but not the best on protection. Simone Giannerini __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 the fortran process when > > linking does not solve the problem > > In general the stack size is also governed by the system limits so > you may need to increase those as well, but still, that won't really > solve your problem. > > >> I'd say your only reasonable workarounds are to tell your compiler to > >> use the heap for the local matrix allocation (if that's possible), > >> or do > >> your allocations in R. > >> > > > > I might follow the second way, in any case, I am considering > > switching to Linux, I have also considered changing compiler under > > Win, any suggestions on the choice would be welcomed. > > As Duncan was mentioning g77 is your friend if you can convert your > code to f77. If you don't have that option, you're partially on your > own. GNU Fortran 95 (gfortran) may be an option as it exists both for > unix and Windows (although not as a part of MinGW), but R currently > doesn't provide .f90 target so you'll need to add your own small > Makevars. > > Cheers, > Simon > > Many thanks, I did not know about gfortran for Windows, I will have a look at it. Kind regards, Simone -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 master in a few hours). Maintainers of packages that produce an ERROR now and have not produced an ERROR before have just been notified by automatical generated messages. All others might want to check whether there is a WARNING for their packages. Best, Uwe Ligges __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 few specific questions: ptr_R_EditFile: I can find exactly one point in the R-sources where ptr_R_EditFile acutally seems to be used (at least if non-NULL). By default the pointer is set to NULL with the comment "for futur expansion". I wonder: 1) Why is this needed at all? Shouldn't the more generic R_EditFiles (ptr_R_EditFiles) suffice for the more specific case of editing a single file? 2) Why is ptr_R_EditFiles only available on aqua? Ok, it says on other platforms this does not currently work. But if I'd be able to create a working implementation in my application, why shouldn't I be allowed to override it (ok, I still can by just declaring it extern, but it's not exported in rinterface.h)? R could still check ptr_R_EditFiles for NULL before using it. 3) Am I correct in assuming that the parameter char* buf is supposed to keep the filename? 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 initializes all the callbacks to the standard values. 2) That aside, what is the policy for R_ShowMessage? Can I assume all messages being shown this way are errors of some sort? Or could there also be mere informational messages (which in a GUI would be presented in slightly different ways)? R_WriteConsole (ptr_R_WriteConsole): This is a great callback. It will allow me to get rid of my hacky sinks (currently I use a sink to a file to retrieve the output). Even better would be an additional callback ptr_R_WriteErr. Is there any particular reason, why this does not exist? Could it be added? Thanks! Thomas __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
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 initializes all the > callbacks to the standard values. Sorry, of course I meant to write Rf_initEmbeddedR (...). I got confused as I have this and a few other initialization calls in a functions called startR (...). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[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 to promote it a little bit, or if you simply have an interesting application using R, we hope you can find some time to write a short article on it. We suggest that it be approximately 3 pages or less. The idea of the newsletter is that it be interesting to R users without being too technical. For example an article describing a package could begin by briefly outlining the statistical background and go on to demonstrate the usage on some typical data set. Of course graphics are more than welcome! Bill Venables <[EMAIL PROTECTED]> is also encouraging submissions to the more specialist Programmer's Niche column. In this case the technical level could be a little higher, of course, but not necessarily: ingeniousness is the key. The R Help Desk column is intended to present answers to frequently asked questions as well as tricks that are useful to the majority of useRs. Please send submissions to Uwe Ligges <[EMAIL PROTECTED]>. The deadline for submissions is October, 8th, 2005 Keep the contributions rolling in! The Editorial Board, Doug Bates, Paul Murrell and Torsten Hothorn __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
