similar to: large sysdata.rda file --- strategies?

Hi, recently R CMD check --as-cran has noticed some more issues with package namespace imports with the recommended remedy to use importFrom() and friends. In my case, there was only a conflict restricted to some few imports, while I would prefer to still import all the non-conflicting objects, methods, and classes of the respective package namespace. So would it be possible to have some new

------------------------------------------------------------------------ ------------------------------------------------------------------------ New versions 2.3 of our distr-family of packages are now available on CRAN. (i.e.; startupmsg, SweaveListingUtils, distr, distrEx, distrDoc, distrEllipse, distrMod, distrSim, distrTEst, distrTeach) Most importantly, we have included: +

------------------------------------------------------------------------ ------------------------------------------------------------------------ New versions 2.3 of our distr-family of packages are now available on CRAN. (i.e.; startupmsg, SweaveListingUtils, distr, distrEx, distrDoc, distrEllipse, distrMod, distrSim, distrTEst, distrTeach) Most importantly, we have included: +

Hi R-devels, recently, we have seen a new warning by "R CMD check" appearing for the devel-version of our package distrEx available on r-forge, e.g. as *|install.packages("/distrEx/",repos="http://r-forge.r-project.org")|* Here is the warning: %--------------------- [...snip ...] * checking for unstated dependencies in R code ... WARNING .get_S4_methods_list():

Hi R-devels, latetely I reported having problems with understanding warnings issued by a devel version of R CMD check, which Brian Ripley in his reply https://stat.ethz.ch/pipermail/r-devel/2008-August/050493.html correctly attributed to my using an outdated version (July 29) --- you really have to be quick with updating these days! Having switched to a more recent version, R CMD check

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

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

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:

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

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, 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

Hi all, I'm struggling with accessing a package dataset (munsell.map, stored in sysdata.rda) when that package is imported, not required. A simple reproducible example is: install.packages("munsell") munsell::mnsl("10B 4/6") # Error in match(col, munsell.map$name) : object 'munsell.map' not found library(munsell) munsell::mnsl("10B 4/6") # Function

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

The Fraunhofer Institute for Industrial Mathematics ITWM in Kaiserslauern, Germany, is looking for a researcher in its department for Financial Mathematics, starting as soon as possible. We are a team working in the following domains of research and industrial projects: Development of models and algorithms for pricing of financial derivatives; evaluation, optimization and risk assessment of

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

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

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