similar to: sysdata.rda, namespaces and package dependencies

Dear developeRs, my package FrF2.catlg128 holds large catalogues and is supposed to gain additional ones. All the catalogues are intended for the user. So far, the catalogues were stored in the data directory, and LazyData was "no". I understand that this is not considered wise any more (if it ever was), so that I want to change to LazyData "yes" with the next release

Hi, to speed up computations in our RobASt family of packages, we use interpolation on a grid of precomputed values which we save together with the interpolating functions (results of splinefun essentially) in sysdata.rda in the R folder of our pkg. After adding grids for some more models, this file has grown considerably, even after application of tools::resaveRdaFiles. At the moment we are at

Hi, I am getting a strange error with 15.0 which I've not seen with previous versions of R. If sysdata.rda is included in R directory of the package I am getting: R CMD build betfairly.roxygen/ * checking for file ?betfairly.roxygen/DESCRIPTION? ... OK * preparing ?betfairly?: * checking DESCRIPTION meta-information ... OK * excluding invalid files Subdirectory 'R' contains invalid

The R 4.0.0 package migration on Debian is being held back by a failed build on ppc64el [1]. We can see from the history of builds logs [2] that it used to build, briefly failed, worked again and then failed leading to R 4.0.0's release. (And my bad for missing how the alpha1/alpha2/beta/rc builds failed.) I have however neither changed anything, nor did I ever have to accomodate ppc64el (as

On 30 April 2020 at 09:11, luke-tierney at uiowa.edu wrote: | On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: | Maybe I missed something. How is the 'compiler' package involved? See the other email thread; you replied (~ 26 hours ago) to my message adding that "sysdata.rda in 'tools' hanging was wrong". It gets to the next stage, which is 'compiler'. We know by

Hi r-devels, we are seeing a new problem with our packages RobAStRDA (just new on CRAN, thanks to Uwe and Kurt!) and RobExtremes (to be submitted). It must be something recent with the way you internally treat/store byte-code compiled functions, as we have no problems with R-3.1.3, but do see an "Error in fct(x) : byte code version mismatch" with R-devel SVNrev r70532. Background:

Thanks, Luke, for having a look to it. Sure, I can give you some reproducible example -- even in two degrees of completeness ;-): see below. Thanks again, Peter %----------------------------------- (I) first example %----------------------------------- Just to reproduce the error, on r-devel, try: install.packages("RobAStRDA") require(RobAStRDA) getFromNamespace(".RMXE", ns

Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. -pd > On 29 Apr 2020, at 01:17 , Dirk Eddelbuettel <edd at

I can't reproduce the more complex version. But the package on CRAN fails in the same way on 3.2.3 and 3.3.0. The problem is that your sysdata.rda includes a function that is generating this error. If you do f <- getFromNamespace(".RMXE", ns ="RobAStRDA")[["GEVFamily"]][["fun.N"]][[1]] g <- get("fct", environment(f)) and look at the

On 30 April 2020 at 09:42, I?aki Ucar wrote: | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: | > And to keep the list abreast, this appears to be related to the long double | > issue on powerpc where needed an extra #define to ensure compilation. That [...] | Which reminds me that [1] was required for v3.6.2. Could be related? Yes, that is what I refered

Can you provide a complete reproducible example? Sent from my iPhone > On May 1, 2016, at 6:51 AM, Peter Ruckdeschel <peter.ruckdeschel at web.de> wrote: > > Hi r-devels, > > we are seeing a new problem with our packages RobAStRDA (just new on CRAN, thanks > to Uwe and Kurt!) and RobExtremes (to be submitted). > > It must be something recent with the way you

On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > > > On 29 April 2020 at 11:22, peter dalgaard wrote: > | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is

On Thu, 30 Apr 2020, Dirk Eddelbuettel wrote: > > On 30 April 2020 at 09:42, I?aki Ucar wrote: > | On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel <edd at debian.org> wrote: > | > And to keep the list abreast, this appears to be related to the long double > | > issue on powerpc where needed an extra #define to ensure compilation. That > [...] > | Which reminds me

On 29 April 2020 at 11:22, peter dalgaard wrote: | Hum, at least it is not Apple, so maybe you can attach a debugger to the running process? (gdb -p process_id or something like that --- haven't actually done it for a decade). Then at least we can get a stack trace and a clue about where it is looping. Diddling optimization options can also sometimes provide a clue. (Missed this earlier as

On 2015-12-30 09:58, Michael Felt wrote: > On 2015-12-29 11:02, Michael Felt wrote: >> This seems to be a problem that goes back a long time - and I hope >> someone who understands what tre is suppossed to be doing will look >> at this. >> >> A short history of other people who have reported on this on >> different versions of AIX. I shall only add that I

Ok, found the problem - on platforms that support it TRE uses wint_t (from wchar.h) as its type for characters (tre_cint_t) which on AIX is *signed* int. TRE uses liberally conversions between int and tre_cint_t apparently assuming that the latter is unsigned so conversions back to int are suitable for comparisons etc. On other platforms wint_t is unsigned so it works. Manually defining tre_cint_t

This seems to be a problem that goes back a long time - and I hope someone who understands what tre is suppossed to be doing will look at this. A short history of other people who have reported on this on different versions of AIX. I shall only add that I get the same results on AIX 5.3 TL7, AIX 6.1 TL9 and AIX 7.1 TL3. Basically, with settings that work for AIX and 32-bit - the only changes

Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/

On 2016-01-01 23:48, peter dalgaard wrote: > Nice catch you two!!! > > Happy New Year > -pd I am much happier with this great start! Simon - which compiler)s) did you use: xlc and xlfortran, or gcc/gfortran? I have made some changes to configure(.ac) so maybe my problems are self-inflicted. But would be good to know what environment you are using. Thanks for looking - and

Hello, My package has passed all the R CMD CHECK steps except one. There is an object which I placed in a sysdata.rda file (located in the 'R' directory of the source package). Even though users have no need to access this object, which is a character vector of parameters fed to Fortran code, R CMD CHECK produces a warning that it needs documentation. So I made an .Rd file for it. However,