diff --git a/r-devel/2024-May.txt b/r-devel/2024-May.txt new file mode 100644 index 0000000..ee2d5d0 --- /dev/null +++ b/r-devel/2024-May.txt @@ -0,0 +1,631 @@ +From th|erry@onke||nx @end|ng |rom |nbo@be Mon May 6 08:45:57 2024 +From: th|erry@onke||nx @end|ng |rom |nbo@be (Thierry Onkelinx) +Date: Mon, 6 May 2024 08:45:57 +0200 +Subject: [Rd] [R-sig-ME] lmer error: number of observations <= number of + random effects +In-Reply-To: +References: +Message-ID: + +Dear Srinidhi, + +You are trying to fit 1 random intercept and 2 random slopes per +individual, while you have at most 3 observations per individual. You +simply don't have enough data to fit the random slopes. Reduce the random +part to (1|ID). + +Best regards, + +Thierry + +ir. Thierry Onkelinx +Statisticus / Statistician + +Vlaamse Overheid / Government of Flanders +INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND +FOREST +Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +thierry.onkelinx at inbo.be +Havenlaan 88 bus 73, 1000 Brussel +*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +*Poststukken die naar dit adres worden gestuurd, worden ingescand en +digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +dossiers volledig digitaal behandelen. Poststukken met de vermelding +?vertrouwelijk? worden niet ingescand, maar ongeopend aan de geadresseerde +bezorgd.* +www.inbo.be + +/////////////////////////////////////////////////////////////////////////////////////////// +To call in the statistician after the experiment is done may be no more +than asking him to perform a post-mortem examination: he may be able to say +what the experiment died of. ~ Sir Ronald Aylmer Fisher +The plural of anecdote is not data. ~ Roger Brinner +The combination of some data and an aching desire for an answer does not +ensure that a reasonable answer can be extracted from a given body of data. +~ John Tukey +/////////////////////////////////////////////////////////////////////////////////////////// + + + + +Op ma 6 mei 2024 om 01:59 schreef Srinidhi Jayakumar via R-sig-mixed-models +: + +> I am running a multilevel growth curve model to examine predictors of +> social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +> continuous numeric variable. The age variable (Index1) has been coded as 0 +> for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +> varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +> to examine whether trajectory/variation in LSI predicts difference in SA +> trajectory. LSI is a continuous numeric variable and was grand-mean +> centered before using in the models. The data has been converted to long +> format with SA in 1 column, LSI in the other, ID in another, and age in +> another column. I used the code below to run my model using lmer. However, +> I get the following error. Please let me know how I can solve this error. +> Please note that I have 50% missing data in SA at age 12. +> modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +> summary(modelLSI_maineff_RE) +> Error: number of observations (=1080) <= number of random effects (=1479) +> for term (1 + Index1 + LSI | ID); the random-effects parameters and the +> residual variance (or scale parameter) are probably unidentifiable +> +> I did test the within-person variance for the LSI variable and the +> within-person variance is significant from the Greenhouse-Geisser, +> Hyunh-Feidt tests. +> +> I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +> me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +> Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +> "ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +> "ignore", tol = 1e-4)), REML=TRUE) +> +> summary(modelLSI_maineff_RE) +> Linear mixed model fit by REML. t-tests use Satterthwaite's method +> ['lmerModLmerTest'] +> Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +> Data: LSIDATA +> Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +> check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) +> +> REML criterion at convergence: 7299.6 +> +> Scaled residuals: +> Min 1Q Median 3Q Max +> -2.7289 -0.4832 -0.1449 0.3604 4.5715 +> +> Random effects: +> Groups Name Variance Std.Dev. Corr +> ID (Intercept) 30.2919 5.5038 +> Index1 2.4765 1.5737 -0.15 +> LSI 0.1669 0.4085 -0.23 0.70 +> Residual 24.1793 4.9172 +> Number of obs: 1080, groups: ID, 493 +> +> Fixed effects: +> Estimate Std. Error df t value Pr(>|t|) +> (Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +> Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +> LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +> Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +> Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 +> +> Correlation of Fixed Effects: +> (Intr) Index1 LSI +> Index1 -0.645 +> LSI -0.032 0.057 +> Index1:LSI 0.015 0.037 -0.695 +> +> I am a little vary of the output still as the error states that I have +> equal observations as the number of random effects (i.e., 3 observations +> per ID and 3 random effects). Hence, I am wondering whether I can simplify +> the model as either of the below models and choose the one with the +> best-fit statistics: +> +> modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* +> +> modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +> lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-sig-mixed-models at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> + + [[alternative HTML version deleted]] + + +From @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu Mon May 6 01:58:35 2024 +From: @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu (Srinidhi Jayakumar) +Date: Sun, 5 May 2024 19:58:35 -0400 +Subject: [Rd] lmer error: number of observations <= number of random effects +Message-ID: + +I am running a multilevel growth curve model to examine predictors of +social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +continuous numeric variable. The age variable (Index1) has been coded as 0 +for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +to examine whether trajectory/variation in LSI predicts difference in SA +trajectory. LSI is a continuous numeric variable and was grand-mean +centered before using in the models. The data has been converted to long +format with SA in 1 column, LSI in the other, ID in another, and age in +another column. I used the code below to run my model using lmer. However, +I get the following error. Please let me know how I can solve this error. +Please note that I have 50% missing data in SA at age 12. +modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +summary(modelLSI_maineff_RE) +Error: number of observations (=1080) <= number of random effects (=1479) +for term (1 + Index1 + LSI | ID); the random-effects parameters and the +residual variance (or scale parameter) are probably unidentifiable + +I did test the within-person variance for the LSI variable and the +within-person variance is significant from the Greenhouse-Geisser, +Hyunh-Feidt tests. + +I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +"ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +"ignore", tol = 1e-4)), REML=TRUE) + +summary(modelLSI_maineff_RE) +Linear mixed model fit by REML. t-tests use Satterthwaite's method +['lmerModLmerTest'] +Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +Data: LSIDATA +Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) + +REML criterion at convergence: 7299.6 + +Scaled residuals: +Min 1Q Median 3Q Max +-2.7289 -0.4832 -0.1449 0.3604 4.5715 + +Random effects: +Groups Name Variance Std.Dev. Corr +ID (Intercept) 30.2919 5.5038 +Index1 2.4765 1.5737 -0.15 +LSI 0.1669 0.4085 -0.23 0.70 +Residual 24.1793 4.9172 +Number of obs: 1080, groups: ID, 493 + +Fixed effects: +Estimate Std. Error df t value Pr(>|t|) +(Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 + +Correlation of Fixed Effects: +(Intr) Index1 LSI +Index1 -0.645 +LSI -0.032 0.057 +Index1:LSI 0.015 0.037 -0.695 + +I am a little vary of the output still as the error states that I have +equal observations as the number of random effects (i.e., 3 observations +per ID and 3 random effects). Hence, I am wondering whether I can simplify +the model as either of the below models and choose the one with the +best-fit statistics: + + modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* + +modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] + + + [[alternative HTML version deleted]] + + +From tr@ver@c @end|ng |rom gm@||@com Sat May 11 02:39:53 2024 +From: tr@ver@c @end|ng |rom gm@||@com (Travers Ching) +Date: Fri, 10 May 2024 17:39:53 -0700 +Subject: [Rd] R hang/bug with circular references and promises +Message-ID: + +The following code snippet causes R to hang. This example might be a +bit contrived as I was experimenting and trying to understand +promises, but uses only base R. + +It looks like it is looking for "not_a_variable" recursively but since +it doesn't exist it goes on indefinitely. + +x0 <- new.env() +x1 <- new.env(parent = x0) +parent.env(x0) <- x1 +delayedAssign("v", not_a_variable, eval.env=x1) +delayedAssign("w", v, assign.env=x1, eval.env=x0) +x1$w + + +From iuke-tier@ey m@iii@g oii uiow@@edu Sat May 11 03:34:19 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Fri, 10 May 2024 20:34:19 -0500 (CDT) +Subject: [Rd] + [External] R hang/bug with circular references and promises +In-Reply-To: +References: +Message-ID: + +On Sat, 11 May 2024, Travers Ching wrote: + +> The following code snippet causes R to hang. This example might be a +> bit contrived as I was experimenting and trying to understand +> promises, but uses only base R. +> +> It looks like it is looking for "not_a_variable" recursively but since +> it doesn't exist it goes on indefinitely. +> +> x0 <- new.env() +> x1 <- new.env(parent = x0) +> parent.env(x0) <- x1 +> delayedAssign("v", not_a_variable, eval.env=x1) +> delayedAssign("w", v, assign.env=x1, eval.env=x0) +> x1$w + +This has nothing to do with promises. You created a cycle in the +environment chain. A simpler variant: + +e <- new.env() +parent.env(e) <- e +get("x", e) + +This will hang and is not interruptable -- loops searching up +environment chains are too speed-critical to check for interrupts. It +is, however, pretty easy to check whether the parent change would +create a cycle and throw an error if it would. Need to think a bit +about exactly where the check should go. + +Best, + +luke + +> +> ______________________________________________ +> R-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-devel +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/ + + +From peter@|@ng|e|der @end|ng |rom gm@||@com Sat May 11 17:03:07 2024 +From: peter@|@ng|e|der @end|ng |rom gm@||@com (Peter Langfelder) +Date: Sat, 11 May 2024 23:03:07 +0800 +Subject: [Rd] + [External] R hang/bug with circular references and promises +In-Reply-To: +References: + +Message-ID: + +On Sat, May 11, 2024 at 9:34?AM luke-tierney--- via R-devel + wrote: +> +> On Sat, 11 May 2024, Travers Ching wrote: +> +> > The following code snippet causes R to hang. This example might be a +> > bit contrived as I was experimenting and trying to understand +> > promises, but uses only base R. +> +> This has nothing to do with promises. You created a cycle in the +> environment chain. A simpler variant: +> +> e <- new.env() +> parent.env(e) <- e +> get("x", e) +> +> This will hang and is not interruptable -- loops searching up +> environment chains are too speed-critical to check for interrupts. It +> is, however, pretty easy to check whether the parent change would +> create a cycle and throw an error if it would. Need to think a bit +> about exactly where the check should go. + +FWIW, the help for parent.env already explicitly warns against using +parent.env <-: + +The replacement function ?parent.env<-? is extremely dangerous as + it can be used to destructively change environments in ways that + violate assumptions made by the internal C code. It may be + removed in the near future. + +Peter + + +From @vr@h@m@@d|er @end|ng |rom gm@||@com Mon May 13 07:56:57 2024 +From: @vr@h@m@@d|er @end|ng |rom gm@||@com (Avraham Adler) +Date: Mon, 13 May 2024 01:56:57 -0400 +Subject: [Rd] Change between 86152 and 86534 - probably 86265 - that looks + for zspmv in BLAS and not LAPACK causes R with OpenBLAS to fail +Message-ID: + +Executive summary: + +I believe revision 86265 makes it more difficult to build R with +OpenBLAS on Windows as now the entire LAPACK needs to be built to +obtain zspmv. Is there anything that can be done to allow the former +behavior to be used, something in Mkrules.local perhaps? + +Detailed Explanation: + +I have been building R with OpenBLAS for Windows 64 for over a decade +by patching /src/extra/blas/Makevars.win as follows: + +--- /c/r/trunk/src/extra/blas/Makefile.win 2024-01-24 +18:34:42.755255900 +0000 ++++ /c/r/Makefile.win 2024-01-24 18:39:39.716458000 +0000 +@@ -12,7 +12,7 @@ + ../../../$(BINDIR)/Rblas.dll: blas00.o ../../gnuwin32/dllversion.o + @$(ECHO) -------- Building $@ -------- + $(DLL) -s -shared $(DLLFLAGS) -o $@ $^ Rblas.def \ +- -L../../../$(IMPDIR) -lR -L"$(ATLAS_PATH)" -lf77blas -latlas ++ -L../../../$(IMPDIR) -lR -L"$(ATLAS_PATH)" -fopenmp -lopenblas + else + ../../../$(BINDIR)/Rblas.dll: blas.o blas2.o cmplxblas.o cmplxblas2.o +../../gnuwin32/dllversion.o + @$(ECHO) -------- Building $@ -------- + +and then passing USE_ATLAS = YES and ATLAS_PATH = C:/R/OPB/whatever in +Mkrules.local + +When I compile OpenBLAS, I have always done so with NO_CBLAS, +NO_LAPACK, and NO_SHARED, as the Windows toolchain does not need +CBLAS, a shared library, or allow for a separate LAPACK and this has +worked, for the most part, since roughly 2013. +When building the recent R-devel (a revision slightly before 86534), +the compilation stopped when building Rblas with the following error: + +-------- Building ../../../bin/x64/Rblas.dll -------- +gcc -s -shared -o ../../../bin/x64/Rblas.dll blas00.o +../../gnuwin32/dllversion.o Rblas.def \ + -L../../../bin/x64 -lR -L"C:/R/OPB/OpenBLAS-develop-f0560f9" +-fopenmp -lopenblas +C:\rtools44\x86_64-w64-mingw32.static.posix\bin/ld.exe: cannot export +zspmv_: symbol not defined +collect2.exe: error: ld returned 1 exit status +make[4]: *** [Makefile.win:14: ../../../bin/x64/Rblas.dll] Error 1 +make[3]: *** [Makefile:227: Rblas] Error 2 +make[2]: *** [Makefile:116: rbuild] Error 2 +make[1]: *** [Makefile:17: all] Error 2 +make: *** [Makefile:392: distribution] Error 2 + +I reached out to OpenBLAS (there were other issues with OPB 0.3.27) +and one of the maintainers responded: + +> "for historical reasons, ZSPMV is in LAPACK although conceptionally [sic] it belongs in BLAS. As you specified NO_LAPACK=1, this function gets omitted since 0.3.20 to allow combining the BLAS-only build with an external LAPACK." [1] + +He later followed up with "0.3.26 built with NO_LAPACK=1 will likewise +omit the zspmv symbol (as directed)." [2] + +I last successfully compiled v86152 with OpenBLAS 0.3.26 on +2024-03-19. When I compiled 86534 tonight with OPB 0.3.27, I got the +error above. I then tried with OPB 0.3.26?which worked for 86152?and +still got the zspmv error. + +I am guessing this relates to revision 86265 "amending r85873: zspmv +is BLAS, not Lapack?" [3]. + +I built OpenBLAS AND its LAPACK, which takes MUCH MUCH longer, and +tried building R. This time, the build succeeded and passes make +check-devel. + +Is there any way to allow the former functionality if the build +recognizes the use of OpenBLAS? Is the only option to compile +OpenBLAS's LAPACK too? + +Thank you, + +Avi + + +[1] https://github.com/OpenMathLib/OpenBLAS/issues/4684#issuecomment-2101123154 +[2] https://github.com/OpenMathLib/OpenBLAS/issues/4684#issuecomment-2101213474 +[3] https://github.com/r-devel/r-svn/commit/c9f3aba39aa89821d294f4a524331a21e6904aec + + +From iuke-tier@ey m@iii@g oii uiow@@edu Mon May 13 16:54:27 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Mon, 13 May 2024 09:54:27 -0500 (CDT) +Subject: [Rd] + [External] R hang/bug with circular references and promises +In-Reply-To: +References: + + +Message-ID: <988ea195-1fbe-9e54-d68c-64f6bf36f9a0@uiowa.edu> + +On Sat, 11 May 2024, Peter Langfelder wrote: + +> On Sat, May 11, 2024 at 9:34?AM luke-tierney--- via R-devel +> wrote: +>> +>> On Sat, 11 May 2024, Travers Ching wrote: +>> +>>> The following code snippet causes R to hang. This example might be a +>>> bit contrived as I was experimenting and trying to understand +>>> promises, but uses only base R. +>> +>> This has nothing to do with promises. You created a cycle in the +>> environment chain. A simpler variant: +>> +>> e <- new.env() +>> parent.env(e) <- e +>> get("x", e) +>> +>> This will hang and is not interruptable -- loops searching up +>> environment chains are too speed-critical to check for interrupts. It +>> is, however, pretty easy to check whether the parent change would +>> create a cycle and throw an error if it would. Need to think a bit +>> about exactly where the check should go. +> +> FWIW, the help for parent.env already explicitly warns against using +> parent.env <-: +> +> The replacement function ?parent.env<-? is extremely dangerous as +> it can be used to destructively change environments in ways that +> violate assumptions made by the internal C code. It may be +> removed in the near future. + +Looks like I added that warning 22 years ago, so that should be enough +notice :-). I'll look into removing it now. + +Best, + +luke + +> +> Peter +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu + +From |kry|ov @end|ng |rom d|@root@org Mon May 13 17:44:27 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Mon, 13 May 2024 18:44:27 +0300 +Subject: [Rd] + [External] R hang/bug with circular references and promises +In-Reply-To: <988ea195-1fbe-9e54-d68c-64f6bf36f9a0@uiowa.edu> +References: + + + <988ea195-1fbe-9e54-d68c-64f6bf36f9a0@uiowa.edu> +Message-ID: <20240513184427.0ba6a251@arachnoid> + +On Mon, 13 May 2024 09:54:27 -0500 (CDT) +luke-tierney--- via R-devel wrote: + +> Looks like I added that warning 22 years ago, so that should be enough +> notice :-). I'll look into removing it now. + +Dear Luke, + +I've got a somewhat niche use case: as a way of protecting myself +against rogue *.rds files and vulnerabilities in the C code, I've been +manually unserializing "plain" data objects (without anything +executable), including environments, in R [1]. + +I see that SET_ENCLOS() is already commented as "not API and probably +should not be <...> used". Do you think there is a way to recreate an +environment, taking the REFSXP entries into account, without +`parent.env<-`? Would you recommend to abandon the folly of +unserializing environments manually? + +-- +Best regards, +Ivan + +[1] +https://codeberg.org/aitap/unserializeData/src/commit/33d72705c1ee265349b3e369874ce4b47f9cd358/R/unserialize.R#L289-L313 + + +From iuke-tier@ey m@iii@g oii uiow@@edu Mon May 13 19:26:48 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Mon, 13 May 2024 12:26:48 -0500 (CDT) +Subject: [Rd] + [External] R hang/bug with circular references and promises +In-Reply-To: <20240513184427.0ba6a251@arachnoid> +References: + + + <988ea195-1fbe-9e54-d68c-64f6bf36f9a0@uiowa.edu> + <20240513184427.0ba6a251@arachnoid> +Message-ID: + +On Mon, 13 May 2024, Ivan Krylov wrote: + +> [You don't often get email from ikrylov at disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] +> +> On Mon, 13 May 2024 09:54:27 -0500 (CDT) +> luke-tierney--- via R-devel wrote: +> +>> Looks like I added that warning 22 years ago, so that should be enough +>> notice :-). I'll look into removing it now. +> + +For now I have just changed the internal code to throw an error +if the change would produce a cycle (r86545). This gives + + > e <- new.env() + > parent.env(e) <- e + Error in `parent.env<-`(`*tmp*`, value = ) : + cycles in parent chains are not allowed + +> Dear Luke, +> +> I've got a somewhat niche use case: as a way of protecting myself +> against rogue *.rds files and vulnerabilities in the C code, I've been +> manually unserializing "plain" data objects (without anything +> executable), including environments, in R [1]. + +I would try using two passes: create the environments in the first pass +and in a second pass, either over the file or a new object with place holders, fill them in. + +> I see that SET_ENCLOS() is already commented as "not API and probably +> should not be <...> used". Do you think there is a way to recreate an +> environment, taking the REFSXP entries into account, without +> `parent.env<-`? Would you recommend to abandon the folly of +> unserializing environments manually? + +SET_ENCLOS is one of a number of SET... functions that are not in the +API and should not be since they are potentially unsafe to use. (One +that is in the API and needs to be removed is SET_TYPEOF). So we would +like to move them out of installed headers and not export them as +entry points. For this particular case most uses I see are something +like + + env = allocSExp(ENVSXP); + SET_FRAME(env, R_NilValue); + SET_ENCLOS(env, parent); + SET_HASHTAB(env, R_NilValue); + SET_ATTRIB(env, R_NilValue); + +which could just use + + env = R_NewEnv(parent, FALSE, 0); + +Best, + +luke + +> +> -- +> Best regards, +> Ivan +> +> [1] +> https://codeberg.org/aitap/unserializeData/src/commit/33d72705c1ee265349b3e369874ce4b47f9cd358/R/unserialize.R#L289-L313 +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/ + + diff --git a/r-help/2024-May.txt b/r-help/2024-May.txt new file mode 100644 index 0000000..02b8cbf --- /dev/null +++ b/r-help/2024-May.txt @@ -0,0 +1,4372 @@ +From t|m@how@rd @end|ng |rom dec@ny@gov Wed May 1 18:57:18 2024 +From: t|m@how@rd @end|ng |rom dec@ny@gov (Howard, Tim G (DEC)) +Date: Wed, 1 May 2024 16:57:18 +0000 +Subject: [R] De-serialization vulnerability? +In-Reply-To: +References: +Message-ID: + +All, +There seems to be a hullaboo about a vulnerability in R when deserializing untrusted data: + +https://hiddenlayer.com/research/r-bitrary-code-execution + +https://nvd.nist.gov/vuln/detail/CVE-2024-27322 + +https://www.kb.cert.org/vuls/id/238194 + + +Apparently a fix was made for R 4.4.0, but I see no mention of it in the changes report: + +https://cloud.r-project.org/bin/windows/base/NEWS.R-4.4.0.html + +Is this real? Were there changes in R 4.4.0 that aren't reported? + +Of course, we should *always* update to the most recent version, but I was confused why it wasn't mentioned in the release info. + +Thanks, +Tim + + +From |kry|ov @end|ng |rom d|@root@org Wed May 1 19:19:59 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 1 May 2024 20:19:59 +0300 +Subject: [R] De-serialization vulnerability? +In-Reply-To: +References: + +Message-ID: <20240501201959.0b1c65bc@Tarkus> + +? Wed, 1 May 2024 16:57:18 +0000 +"Howard, Tim G \(DEC\) via R-help" ?????: + +> Is this real? + +Yes, but with a giant elephant in the room that many are overlooking. +It has actually always been much worse. + +Until R-4.4.0, there used to be a way for readRDS() to return an +unevaluated "promise object". When you access the returned value, the +code attached to the promise object is evaluated. Starting with +R-4.4.0, this particular ability is now forbidden. One particular +attack is now prevented, but the whole class of attacks is still +fundamentally impossible to avoid. The resulting increase in safety is +very small. + +The R data files, both those produced by save() and opened by load(), +and those produced by saveRDS() and readRDS(), contain _internal_ +object state. The code processing those objects trusts the internal +object state, because it has no other alternative, no other source of +state. This is true of all of base R, CRAN and BioConductor. + +Many R objects contain executable code. For example, many saved models +contain -- as part of this internal state that gets stored inside *.rds +and *.RData files -- executable expressions that produce model matrices +from data frames. It is trivial for any aspiring attacker to take such +an object and replace the model expression with one that would take over +your system. When you perform ordinary R operations on the doctored +object, the attacker-provided "model expression" instead does whatever +the attacker wants. + +The above was just one example of "trusting the internal state". An +attacker can come up with similar attacks for ALTREP objects, 'glue' +strings and a lot of other features of R, without ever touching +promises (the topic of CVE-2024-27322) or exploiting parser +vulnerabilities. + +One safe way to move forward is to set aside a strict subset of R Data +Serialization format that cannot be used to create any executable code +or touch potentially vulnerable state (such as ALTREP, I think) and +reject all other features of RDS. Yes, this abandons the ability to +save model objects and many other great features of R serialization, +including those that make 'parallel' clusters possible. (But we trust +our clusters and should use regular serialize() with them.) I've been +working on this today; it's very raw, not even a package yet, and it +doesn't even read some of my data correctly, but I believe it's a +secure way forward: https://codeberg.org/aitap/unserializeData + +-- +Best regards, +Ivan + + +From ce||ocgw @end|ng |rom gm@||@com Wed May 1 17:32:32 2024 +From: ce||ocgw @end|ng |rom gm@||@com (Carl Witthoft) +Date: Wed, 1 May 2024 11:32:32 -0400 +Subject: [R] strange behavior in base::as.double +Message-ID: + +Hello. +I'm running R 4.4.0 on an iMac Venture 13.5.2 . There appears to be a bug +in as.double(). + +Create a string with a numeric digits followed by a single letter a thru f +(as tho' it's base 16). + +for K in (a,b,c,d, and f ) , as.double( '123K') returns NA +but as.double('123e') returns 123 -- or whatever the first digit is. + +Please let me know if there are additional tests I can try . + + +thanks +Carl Witthoft + + [[alternative HTML version deleted]] + + +From @@r@h@go@|ee @end|ng |rom gm@||@com Wed May 1 21:29:05 2024 +From: @@r@h@go@|ee @end|ng |rom gm@||@com (Sarah Goslee) +Date: Wed, 1 May 2024 15:29:05 -0400 +Subject: [R] strange behavior in base::as.double +In-Reply-To: +References: +Message-ID: + +Hi Carl, + +Not that strange: R thinks you're using scientific notation. Also not a Mac bug. + +> as.double('123e') +[1] 123 +> as.double('123e+0') +[1] 123 +> as.double('123e+1') +[1] 1230 +> as.double('123e-1') +[1] 12.3 + +Can you explain what you're trying to accomplish? + +Sarah + +On Wed, May 1, 2024 at 3:24?PM Carl Witthoft wrote: +> +> Hello. +> I'm running R 4.4.0 on an iMac Venture 13.5.2 . There appears to be a bug +> in as.double(). +> +> Create a string with a numeric digits followed by a single letter a thru f +> (as tho' it's base 16). +> +> for K in (a,b,c,d, and f ) , as.double( '123K') returns NA +> but as.double('123e') returns 123 -- or whatever the first digit is. +> +> Please let me know if there are additional tests I can try . +> +> +> thanks +> Carl Witthoft +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + + +-- +Sarah Goslee (she/her) +http://www.numberwright.com + + +From |kw@|mmo @end|ng |rom gm@||@com Wed May 1 21:32:35 2024 +From: |kw@|mmo @end|ng |rom gm@||@com (Iris Simmons) +Date: Wed, 1 May 2024 15:32:35 -0400 +Subject: [R] strange behavior in base::as.double +In-Reply-To: +References: +Message-ID: + +This happens because "123e" looks like exponential form. This string has no +exponent, so it gets treated as 0 exponent. + +If you're interested in converting hex numbers, append 0x: + +as.numeric("0x123a") + +or use strtoi: + +strtoi("123a", 16) + +On Wed, May 1, 2024, 15:24 Carl Witthoft wrote: + +> Hello. +> I'm running R 4.4.0 on an iMac Venture 13.5.2 . There appears to be a bug +> in as.double(). +> +> Create a string with a numeric digits followed by a single letter a thru f +> (as tho' it's base 16). +> +> for K in (a,b,c,d, and f ) , as.double( '123K') returns NA +> but as.double('123e') returns 123 -- or whatever the first digit is. +> +> Please let me know if there are additional tests I can try . +> +> +> thanks +> Carl Witthoft +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide +> http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. +> + + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Wed May 1 21:33:19 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Wed, 1 May 2024 15:33:19 -0400 +Subject: [R] strange behavior in base::as.double +In-Reply-To: +References: +Message-ID: <311baecb-10ae-4ad4-9d86-b2e5ebd2707d@gmail.com> + +On 01/05/2024 11:32 a.m., Carl Witthoft wrote: +> Hello. +> I'm running R 4.4.0 on an iMac Venture 13.5.2 . There appears to be a bug +> in as.double(). +> +> Create a string with a numeric digits followed by a single letter a thru f +> (as tho' it's base 16). +> +> for K in (a,b,c,d, and f ) , as.double( '123K') returns NA +> but as.double('123e') returns 123 -- or whatever the first digit is. +> +> Please let me know if there are additional tests I can try . + +This has been mentioned in the news recently. 123e was taken as +scientific format, with an implied 0 at the end, i.e. 123e0. That is no +longer true after the recent fix; I'm not sure if it is in R +4.4.0-patched yet. + +Duncan Murdoch + + +From |kry|ov @end|ng |rom d|@root@org Wed May 1 21:48:44 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 1 May 2024 22:48:44 +0300 +Subject: [R] strange behavior in base::as.double +In-Reply-To: +References: +Message-ID: <20240501224844.14da6394@Tarkus> + +? Wed, 1 May 2024 11:32:32 -0400 +Carl Witthoft ?????: + +> but as.double('123e') returns 123 -- or whatever the first digit is. + +Nicely spotted problem! + +Prof. Brian D. Ripley has fixed it in R-devel revision 86436 [*]. Now +as.double('123e') will also return NA. I think that the fix will become +part of R-4.4.1 when it's released. + +-- +Best regards, +Ivan + +[*] +https://github.com/r-devel/r-svn/commit/9069a729f5bf69de8250a4c91dd482fcf64e1154 + + +From pd@|gd @end|ng |rom gm@||@com Thu May 2 11:31:43 2024 +From: pd@|gd @end|ng |rom gm@||@com (peter dalgaard) +Date: Thu, 2 May 2024 11:31:43 +0200 +Subject: [R] De-serialization vulnerability? +In-Reply-To: +References: + +Message-ID: <4E6EDAB7-070D-4F93-9C5D-4EDDF3F2823A@gmail.com> + +As a general matter, security holes are usually not advertised by detailing them in the NEWS file. + +The disclosure of such things goes on a different schedule, typically _after_ binaries are out, at which point editing the NEWS file is too late. + +There are other things that do not go into NEWS: Documentation fixups, etc. What does go in is end-user visible functional changes and items that have an explicit PR# against them. + +- Peter D. + + + +> On 1 May 2024, at 18:57 , Howard, Tim G (DEC) via R-help wrote: +> +> All, +> There seems to be a hullaboo about a vulnerability in R when deserializing untrusted data: +> +> https://hiddenlayer.com/research/r-bitrary-code-execution +> +> https://nvd.nist.gov/vuln/detail/CVE-2024-27322 +> +> https://www.kb.cert.org/vuls/id/238194 +> +> +> Apparently a fix was made for R 4.4.0, but I see no mention of it in the changes report: +> +> https://cloud.r-project.org/bin/windows/base/NEWS.R-4.4.0.html +> +> Is this real? Were there changes in R 4.4.0 that aren't reported? +> +> Of course, we should *always* update to the most recent version, but I was confused why it wasn't mentioned in the release info. +> +> Thanks, +> Tim +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + +-- +Peter Dalgaard, Professor, +Center for Statistics, Copenhagen Business School +Solbjerg Plads 3, 2000 Frederiksberg, Denmark +Phone: (+45)38153501 +Office: A 4.23 +Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com + + +From e@tev@@m @end|ng |rom weh|@edu@@u Fri May 3 02:42:43 2024 +From: e@tev@@m @end|ng |rom weh|@edu@@u (Miguel Esteva) +Date: Fri, 3 May 2024 00:42:43 +0000 +Subject: [R] grDevices segfault when building R4.4.0 on RHEL 9.1. +Message-ID: + +Hi all, + +I seem to be getting segfaults when attempting to build R 4.4.0 on RHEL 9.1 (5.14.0-162.23.1.el9_1.x86_64). Interestingly, it seems to build ok on Rocky 9.1 and 9.3. This is the trace: + + +make[3]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +building package 'grDevices' + +make[4]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +all.R is unchanged + +make[4]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +make[4]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +make[5]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src' + +make[6]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src' + +../../../../library/grDevices/libs/grDevices.so is unchanged + +make[7]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[8]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[9]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[9]: 'cairo.so' is up to date. + +make[9]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[8]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[7]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src/cairo' + +make[6]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src' + +make[5]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices/src' + +make[4]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +make[4]: Entering directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' +byte-compiling package 'grDevices' + + + *** caught segfault *** + +address 0x1801fa8f70, cause 'memory not mapped' + + +Traceback: + + 1: solve.default(rgb) + + 2: solve(rgb) + + 3: drop(whitexyz %*% solve(rgb)) + + 4: make.rgb(red = c(0.625, 0.34), green = c(0.28, 0.595), blue = c(0.155, 0.07), gamma = 1.8, white = "D65", name = "Apple RGB") + + 5: eval(exprs[i], envir) + + 6: eval(exprs[i], envir) + + 7: sys.source(codeFile, env, keep.source = keep.source, keep.parse.data = keep.parse.data) + + 8: doTryCatch(return(expr), name, parentenv, handler) + + 9: tryCatchOne(expr, names, parentenv, handlers[[1L]]) + +10: tryCatchList(expr, classes, parentenv, handlers) + +11: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call, nlines = 1L) prefix <- paste("Error in", dcall, ": ") LONG <- 75L sm <- strsplit(conditionMessage(e), "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && isTRUE(getOption("show.error.messages"))) { cat(msg, file = outFile) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))}) + +12: try(sys.source(codeFile, env, keep.source = keep.source, keep.parse.data = keep.parse.data)) + +13: loadNamespace(package = package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, partial = TRUE) + +14: withCallingHandlers(expr, packageStartupMessage = function(c) tryInvokeRestart("muffleMessage")) + +15: suppressPackageStartupMessages(loadNamespace(package = package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, partial = TRUE)) + +16: code2LazyLoadDB(package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, compress = compress, set.install.dir = set.install.dir) + +17: tools:::makeLazyLoading("grDevices") + +An irrecoverable exception occurred. R is aborting now ... + +make[4]: *** [../../../share/make/lazycomp.mk:9: ../../../library/grDevices/R/grDevices.rdb] Error 139 + +make[4]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +make[3]: *** [Makefile:28: all] Error 2 + +make[3]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library/grDevices' + +make[2]: *** [Makefile:39: R] Error 1 + +make[2]: Leaving directory '/home/esteva.m/R/R-4.4.0/src/library' + +make[1]: *** [Makefile:28: R] Error 1 + +make[1]: Leaving directory '/home/esteva.m/R/R-4.4.0/src' + +make: *** [Makefile:62: R] Error 1 + + +Has anyone run into this? + +cairo-1.17.4-7.el9.x86_64 +cairo-gobject-1.17.4-7.el9.x86_64 +cairo-devel-1.17.4-7.el9.x86_64 +cairo-gobject-devel-1.17.4-7.el9.x86_64 +pango-1.48.7-3.el9.x86_64 +pango-devel-1.48.7-3.el9.x86_64 + +Cheers, + + +Miguel Esteva + + +[WEHI Logo] + + +Walter and Eliza Hall Institute of Medical Research +1G Royal Parade Parkville Victoria 3052 Australia + +www.wehi.edu.au + +Twitter | Facebook | Instagram | Youtube | LinkedIn + + +WEHI acknowledges the Wurundjeri people of the Kulin Nation as the traditional owners of the land where our campuses are located and the continuing connection to country and community. + +Private and confidential +The content of this e-mail and any attachments may be private and confidential, intended only for use of the individual or entity named. If you are not the intended recipient of this message you must not read, forward, print, copy, disclose, use or store in any way the information this e-mail or any attachment contains. If you are not the intended recipient, please notify the sender immediately and delete or destroy all copies of this e-mail and any attachment. + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Fri May 3 13:40:59 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 3 May 2024 14:40:59 +0300 +Subject: [R] grDevices segfault when building R4.4.0 on RHEL 9.1. +In-Reply-To: +References: +Message-ID: <20240503144059.58281559@arachnoid> + +Dear Miguel Esteva, + +I couldn't get a Red Hat "ubi9" container to install enough +dependencies to build R. Is there a way to reproduce your setup on a +virtual machine somewhere? + +On Fri, 3 May 2024 00:42:43 +0000 +Miguel Esteva via R-help wrote: + +> *** caught segfault *** +> +> address 0x1801fa8f70, cause 'memory not mapped' +> +> +> Traceback: +> +> 1: solve.default(rgb) + +This seems to crash inside the BLAS. Which BLAS are you using? Any +custom ./configure arguments? Which compilers are you running? + +To find out more information about the crash, try to follow it with a +debugger. Change directory to src/library/grDevices and run: + +_R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 \ + R_DEFAULT_PACKAGES=NULL LC_ALL=C \ +../../../bin/R -d gdb --vanilla --no-echo -e \ + 'tools:::makeLazyLoading("grDevices")' + +(This assumes building straight from the source directory. Adjust the +paths if you're using a separate build directory.) + +Use the "run" command to start the process. One you see a crash, use +"backtrace" to see the state of the call stack at the place of the +crash, or "backtrace full" to include the contents of local variables. +The first few entries are probably the most important ones. + +Not sure what to do with this information yet, but it might provide +more clues. + +-- +Best regards, +Ivan + + +From tb|e|@kov@ @end|ng |rom @tudent@ethz@ch Fri May 3 13:29:19 2024 +From: tb|e|@kov@ @end|ng |rom @tudent@ethz@ch (Bielakova Tatiana) +Date: Fri, 3 May 2024 11:29:19 +0000 +Subject: [R] Using intervals() function for nlme model - Statistics Lab ETHZ +Message-ID: <9a74d1234c254b40b9a7d5cd119ba08a@student.ethz.ch> + +Dear members of the R-Help Team, + + +we are reaching out to you with a question regarding using intervals() to create inference for nlme() function. + +The maintainer for the nlme package is listed as the R-Core Team and we were advised by moderators of R-Core to write to R-Help to receive help in this case. + + +We are students of Statistics at ETH Zurich currently collaborating with ETH Crop Science lab on a project focused on soybean growth. We are modelling the growth using the nlme function and are facing the issue of creating a valid inference for the nlme model (we are especially interested in confidence intervals for the fixed effects). + + +Based on the documentation of nlme package, the function interval is supported for gls, lme, and lmList classes. Although nlme is not mentioned, we still receive intervals without any errors or warnings. + + +We would be therefore very grateful if you could offer your insights on the following questions: + + * Is the intervals() function appropriate for nlme to create confidence intervals? + + * If not, what do the outputted values represent? + + * Do you have any other recommendations/ ideas on how should we proceed to calculate intervals in R (e.g. more suitable packages)? + + +Your help is greatly appreciated. + + +We are looking forward to hearing back from you! + + + +Yours sincerely, + +Tatiana, Marvin & Paul + +from + +Statistics Lab + + + [[alternative HTML version deleted]] + + +From dynvec @end|ng |rom gm@||@com Fri May 3 14:47:27 2024 +From: dynvec @end|ng |rom gm@||@com (DynV Montrealer) +Date: Fri, 3 May 2024 08:47:27 -0400 +Subject: [R] Get a copy of a matrix only for TRUE entries of a matching size + boolean matrix? +Message-ID: + +Is there a way to get a copy of a matrix only for TRUE entries of a +matching size boolean matrix? For *example*: +> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +> mat_letters + [,1] [,2] +[1,] "A" "B" +[2,] "C" "D" +> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) +> mat_bools + [,1] [,2] +[1,] FALSE TRUE +[2,] TRUE FALSE +*Reminder:* The following is only an example ; the solution might look very +different. +some_command(mat_letters, mat_bools, false=empty) + [,1] [,2] +[1,] "" "B" +[2,] "C" "" +some_command(mat_letters, mat_bools, false=na) + [,1] [,2] +[1,] NA "B" +[2,] "C" NA + +Thank you kindly + + [[alternative HTML version deleted]] + + +From bbo|ker @end|ng |rom gm@||@com Fri May 3 16:24:15 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Fri, 3 May 2024 10:24:15 -0400 +Subject: [R] + Get a copy of a matrix only for TRUE entries of a matching size + boolean matrix? +In-Reply-To: +References: +Message-ID: + + In two steps: + +result <- matrix(NA_character_, + nrow=nrow(mat_letters), ncol =ncol(mat_letters)) +result[mat_bools] <- mat_letters[mat_bools] + +On 2024-05-03 8:47 a.m., DynV Montrealer wrote: +> Is there a way to get a copy of a matrix only for TRUE entries of a +> matching size boolean matrix? For *example*: +>> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +>> mat_letters +> [,1] [,2] +> [1,] "A" "B" +> [2,] "C" "D" +>> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) +>> mat_bools +> [,1] [,2] +> [1,] FALSE TRUE +> [2,] TRUE FALSE +> *Reminder:* The following is only an example ; the solution might look very +> different. +> some_command(mat_letters, mat_bools, false=empty) +> [,1] [,2] +> [1,] "" "B" +> [2,] "C" "" +> some_command(mat_letters, mat_bools, false=na) +> [,1] [,2] +> [1,] NA "B" +> [2,] "C" NA +> +> Thank you kindly +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + +From m@rc_grt @end|ng |rom y@hoo@|r Fri May 3 16:28:26 2024 +From: m@rc_grt @end|ng |rom y@hoo@|r (Marc Girondot) +Date: Fri, 3 May 2024 16:28:26 +0200 +Subject: [R] + Get a copy of a matrix only for TRUE entries of a matching size + boolean matrix? +In-Reply-To: +References: +Message-ID: <1fea204c-b71c-4a92-ae13-1dfcf6874357@yahoo.fr> + +Is it what you want ? +mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) + +ifelse(mat_bools, mat_letters, "") +ifelse(mat_bools, mat_letters, NA) + + > ifelse(mat_bools, mat_letters, "") + ???? [,1] [,2] +[1,] ""?? "B" +[2,] "C"? "" + > ifelse(mat_bools, mat_letters, NA) + ???? [,1] [,2] +[1,] NA?? "B" +[2,] "C"? NA + +Marc + + + +Le 03/05/2024 ? 14:47, DynV Montrealer a ?crit?: +> Is there a way to get a copy of a matrix only for TRUE entries of a +> matching size boolean matrix? For*example*: +>> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +>> mat_letters +> [,1] [,2] +> [1,] "A" "B" +> [2,] "C" "D" +>> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) +>> mat_bools +> [,1] [,2] +> [1,] FALSE TRUE +> [2,] TRUE FALSE +> *Reminder:* The following is only an example ; the solution might look very +> different. +> some_command(mat_letters, mat_bools, false=empty) +> [,1] [,2] +> [1,] "" "B" +> [2,] "C" "" +> some_command(mat_letters, mat_bools, false=na) +> [,1] [,2] +> [1,] NA "B" +> [2,] "C" NA + + + [[alternative HTML version deleted]] + + +From dynvec @end|ng |rom gm@||@com Fri May 3 16:39:10 2024 +From: dynvec @end|ng |rom gm@||@com (DynV Montrealer) +Date: Fri, 3 May 2024 10:39:10 -0400 +Subject: [R] + Get a copy of a matrix only for TRUE entries of a matching size + boolean matrix? +In-Reply-To: <1fea204c-b71c-4a92-ae13-1dfcf6874357@yahoo.fr> +References: + <1fea204c-b71c-4a92-ae13-1dfcf6874357@yahoo.fr> +Message-ID: + +It's exactly what I was looking for, thanks. I'm replying to the whole +list so others can skip this question, to not waste time on it. + +Bonne fin de journ?e de Montr?al (nous sommes le matin ici) + +On Fri, May 3, 2024 at 10:30?AM Marc Girondot wrote: + +> Is it what you want ? +> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) +> +> ifelse(mat_bools, mat_letters, "") +> ifelse(mat_bools, mat_letters, NA) +> +> > ifelse(mat_bools, mat_letters, "") +> [,1] [,2] +> [1,] "" "B" +> [2,] "C" "" +> > ifelse(mat_bools, mat_letters, NA) +> [,1] [,2] +> [1,] NA "B" +> [2,] "C" NA +> +> Marc +> +> +> +> Le 03/05/2024 ? 14:47, DynV Montrealer a ?crit : +> +> Is there a way to get a copy of a matrix only for TRUE entries of a +> matching size boolean matrix? For **example**: +> +> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) +> mat_letters +> +> [,1] [,2] +> [1,] "A" "B" +> [2,] "C" "D" +> +> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) +> mat_bools +> +> [,1] [,2] +> [1,] FALSE TRUE +> [2,] TRUE FALSE +> *Reminder:* The following is only an example ; the solution might look very +> different. +> some_command(mat_letters, mat_bools, false=empty) +> [,1] [,2] +> [1,] "" "B" +> [2,] "C" "" +> some_command(mat_letters, mat_bools, false=na) +> [,1] [,2] +> [1,] NA "B" +> [2,] "C" NA +> +> +> + + [[alternative HTML version deleted]] + + +From Ro@@@Boy|@n @end|ng |rom uc@|@edu Fri May 3 21:45:08 2024 +From: Ro@@@Boy|@n @end|ng |rom uc@|@edu (Boylan, Ross) +Date: Fri, 3 May 2024 19:45:08 +0000 +Subject: [R] R CMD check vs RStudio check +Message-ID: + +I am trying to figure out why checking my package is deleting my inst/doc/ directory when I do it in RStudio. Along the way I've hit another puzzle. +In RStudio the check runs and is mostly OK, aside from the deletion. But when I try with vanilla R, the check fails almost immediately: +-------------------------powershell--------------------------- +PS C:\Users\rdboylan\Documents\BP\pimex> & $R CMD check . +* using log directory 'C:/Users/rdboylan/Documents/BP/pimex/..Rcheck' +* using R version 4.3.3 (2024-02-29 ucrt) +* using platform: x86_64-w64-mingw32 (64-bit) +* R was compiled by + gcc.exe (GCC) 12.3.0 + GNU Fortran (GCC) 12.3.0 +* running under: Windows Server 2019 x64 (build 17763) +* using session charset: ISO8859-1 +* checking for file './DESCRIPTION' ... ERROR +Required fields missing or empty: + 'Author' 'Maintainer' +* DONE + +Status: 1 ERROR +See + 'C:/Users/rdboylan/Documents/BP/pimex/..Rcheck/00check.log' +for details. + +PS C:\Users\rdboylan\Documents\BP\pimex> $R +C:\Program Files\R\R-4.3.3\bin\R.exe +--------------------------------------------------------------- + +The DESCRIPTION file includes +Authors at R: + utils::person("Ross", "Boylan", + email = "ross.boylan at ucsf.edu", + role = c("aut", "cre", "cph") + ) +but no separate Author or Maintainer field. + +RStudio is using devtools::check; I don't know if it is doing anything extra beyond that. + +I expected that the various ways of running check would be similar, or at least approve of the same DESCRIPTION file. Can anyone help me understand what is going on, and how I can isolate the source of my problem? + +Initially the problem with the directory deletion appeared running check in RStudio; I believe RStudio calls devtools::check, which I assume ultimately does the equivalent of R CMD check. The build invokes a bootstrap.R script I wrote, which in turn runs LyX. And I'm not sure which of these is responsible for deleting the directory. When I invoke bootstrap.R directly from RStudio LyX runs and nothing is deleted. + +R 4.3.3; RStudio 2023.12.1+402; Windows Server 2019 Standard v1809. + +P.S. What's with the "..Rcheck" log directory, which appears literally with the 2 dots? Is this just MS-Windows getting confused and not interpreting .. as the parent directory? + + +From |kry|ov @end|ng |rom d|@root@org Fri May 3 21:52:26 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 3 May 2024 22:52:26 +0300 +Subject: [R] R CMD check vs RStudio check +In-Reply-To: +References: +Message-ID: <20240503225226.3c45e047@Tarkus> + +? Fri, 3 May 2024 19:45:08 +0000 +"Boylan, Ross via R-help" ?????: + +> & $R CMD check . + +> * checking for file './DESCRIPTION' ... ERROR +> Required fields missing or empty: +> 'Author' 'Maintainer' + +You're checking a source package directory. This could work, but it's +much easier and more reliable to (1) build a source tarball using R CMD +build and (2) check the tarball. This is probably part of what +devtools::check() does. (It can also do a lot of other things pre-R CMD +build.) + +The reason checking the source directory is failing is because it's R +CMD build that creates the necessary 'Author' and 'Maintainer' fields +from Authors at R in your DESCRIPTION. + +> P.S. What's with the "..Rcheck" log directory, which appears +> literally with the 2 dots? Is this just MS-Windows getting confused +> and not interpreting .. as the parent directory? + +"..Rcheck" is built from the argument of R CMD check . followed by +".Rcheck". + +-- +Best regards, +Ivan + + +From th|erry@onke||nx @end|ng |rom |nbo@be Mon May 6 08:45:57 2024 +From: th|erry@onke||nx @end|ng |rom |nbo@be (Thierry Onkelinx) +Date: Mon, 6 May 2024 08:45:57 +0200 +Subject: [R] [R-sig-ME] lmer error: number of observations <= number of + random effects +In-Reply-To: +References: +Message-ID: + +Dear Srinidhi, + +You are trying to fit 1 random intercept and 2 random slopes per +individual, while you have at most 3 observations per individual. You +simply don't have enough data to fit the random slopes. Reduce the random +part to (1|ID). + +Best regards, + +Thierry + +ir. Thierry Onkelinx +Statisticus / Statistician + +Vlaamse Overheid / Government of Flanders +INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND +FOREST +Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +thierry.onkelinx at inbo.be +Havenlaan 88 bus 73, 1000 Brussel +*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +*Poststukken die naar dit adres worden gestuurd, worden ingescand en +digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +dossiers volledig digitaal behandelen. Poststukken met de vermelding +?vertrouwelijk? worden niet ingescand, maar ongeopend aan de geadresseerde +bezorgd.* +www.inbo.be + +/////////////////////////////////////////////////////////////////////////////////////////// +To call in the statistician after the experiment is done may be no more +than asking him to perform a post-mortem examination: he may be able to say +what the experiment died of. ~ Sir Ronald Aylmer Fisher +The plural of anecdote is not data. ~ Roger Brinner +The combination of some data and an aching desire for an answer does not +ensure that a reasonable answer can be extracted from a given body of data. +~ John Tukey +/////////////////////////////////////////////////////////////////////////////////////////// + + + + +Op ma 6 mei 2024 om 01:59 schreef Srinidhi Jayakumar via R-sig-mixed-models +: + +> I am running a multilevel growth curve model to examine predictors of +> social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +> continuous numeric variable. The age variable (Index1) has been coded as 0 +> for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +> varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +> to examine whether trajectory/variation in LSI predicts difference in SA +> trajectory. LSI is a continuous numeric variable and was grand-mean +> centered before using in the models. The data has been converted to long +> format with SA in 1 column, LSI in the other, ID in another, and age in +> another column. I used the code below to run my model using lmer. However, +> I get the following error. Please let me know how I can solve this error. +> Please note that I have 50% missing data in SA at age 12. +> modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +> summary(modelLSI_maineff_RE) +> Error: number of observations (=1080) <= number of random effects (=1479) +> for term (1 + Index1 + LSI | ID); the random-effects parameters and the +> residual variance (or scale parameter) are probably unidentifiable +> +> I did test the within-person variance for the LSI variable and the +> within-person variance is significant from the Greenhouse-Geisser, +> Hyunh-Feidt tests. +> +> I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +> me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +> Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +> "ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +> "ignore", tol = 1e-4)), REML=TRUE) +> +> summary(modelLSI_maineff_RE) +> Linear mixed model fit by REML. t-tests use Satterthwaite's method +> ['lmerModLmerTest'] +> Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +> Data: LSIDATA +> Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +> check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) +> +> REML criterion at convergence: 7299.6 +> +> Scaled residuals: +> Min 1Q Median 3Q Max +> -2.7289 -0.4832 -0.1449 0.3604 4.5715 +> +> Random effects: +> Groups Name Variance Std.Dev. Corr +> ID (Intercept) 30.2919 5.5038 +> Index1 2.4765 1.5737 -0.15 +> LSI 0.1669 0.4085 -0.23 0.70 +> Residual 24.1793 4.9172 +> Number of obs: 1080, groups: ID, 493 +> +> Fixed effects: +> Estimate Std. Error df t value Pr(>|t|) +> (Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +> Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +> LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +> Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +> Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 +> +> Correlation of Fixed Effects: +> (Intr) Index1 LSI +> Index1 -0.645 +> LSI -0.032 0.057 +> Index1:LSI 0.015 0.037 -0.695 +> +> I am a little vary of the output still as the error states that I have +> equal observations as the number of random effects (i.e., 3 observations +> per ID and 3 random effects). Hence, I am wondering whether I can simplify +> the model as either of the below models and choose the one with the +> best-fit statistics: +> +> modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* +> +> modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +> lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-sig-mixed-models at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> + + [[alternative HTML version deleted]] + + +From @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu Mon May 6 01:58:35 2024 +From: @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu (Srinidhi Jayakumar) +Date: Sun, 5 May 2024 19:58:35 -0400 +Subject: [R] lmer error: number of observations <= number of random effects +Message-ID: + +I am running a multilevel growth curve model to examine predictors of +social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +continuous numeric variable. The age variable (Index1) has been coded as 0 +for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +to examine whether trajectory/variation in LSI predicts difference in SA +trajectory. LSI is a continuous numeric variable and was grand-mean +centered before using in the models. The data has been converted to long +format with SA in 1 column, LSI in the other, ID in another, and age in +another column. I used the code below to run my model using lmer. However, +I get the following error. Please let me know how I can solve this error. +Please note that I have 50% missing data in SA at age 12. +modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +summary(modelLSI_maineff_RE) +Error: number of observations (=1080) <= number of random effects (=1479) +for term (1 + Index1 + LSI | ID); the random-effects parameters and the +residual variance (or scale parameter) are probably unidentifiable + +I did test the within-person variance for the LSI variable and the +within-person variance is significant from the Greenhouse-Geisser, +Hyunh-Feidt tests. + +I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +"ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +"ignore", tol = 1e-4)), REML=TRUE) + +summary(modelLSI_maineff_RE) +Linear mixed model fit by REML. t-tests use Satterthwaite's method +['lmerModLmerTest'] +Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +Data: LSIDATA +Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) + +REML criterion at convergence: 7299.6 + +Scaled residuals: +Min 1Q Median 3Q Max +-2.7289 -0.4832 -0.1449 0.3604 4.5715 + +Random effects: +Groups Name Variance Std.Dev. Corr +ID (Intercept) 30.2919 5.5038 +Index1 2.4765 1.5737 -0.15 +LSI 0.1669 0.4085 -0.23 0.70 +Residual 24.1793 4.9172 +Number of obs: 1080, groups: ID, 493 + +Fixed effects: +Estimate Std. Error df t value Pr(>|t|) +(Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 + +Correlation of Fixed Effects: +(Intr) Index1 LSI +Index1 -0.645 +LSI -0.032 0.057 +Index1:LSI 0.015 0.037 -0.695 + +I am a little vary of the output still as the error states that I have +equal observations as the number of random effects (i.e., 3 observations +per ID and 3 random effects). Hence, I am wondering whether I can simplify +the model as either of the below models and choose the one with the +best-fit statistics: + + modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* + +modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] + + + [[alternative HTML version deleted]] + + +From tr@@h|@ket @end|ng |rom gm@||@com Mon May 6 09:11:15 2024 +From: tr@@h|@ket @end|ng |rom gm@||@com (TT FF) +Date: Mon, 6 May 2024 08:11:15 +0100 +Subject: [R] [R-sig-ME] lmer error: number of observations <= number of + random effects +In-Reply-To: +References: + +Message-ID: + +See if this paper may help If it helps reducing the model when you have few observations. the (1|ID) may increase the type 1 error. +https://journals.sagepub.com/doi/10.1177/25152459231214454 + +Best + +> On 6 May 2024, at 07:45, Thierry Onkelinx via R-sig-mixed-models wrote: +> +> Dear Srinidhi, +> +> You are trying to fit 1 random intercept and 2 random slopes per +> individual, while you have at most 3 observations per individual. You +> simply don't have enough data to fit the random slopes. Reduce the random +> part to (1|ID). +> +> Best regards, +> +> Thierry +> +> ir. Thierry Onkelinx +> Statisticus / Statistician +> +> Vlaamse Overheid / Government of Flanders +> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND +> FOREST +> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +> thierry.onkelinx at inbo.be +> Havenlaan 88 bus 73, 1000 Brussel +> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +> *Poststukken die naar dit adres worden gestuurd, worden ingescand en +> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +> dossiers volledig digitaal behandelen. Poststukken met de vermelding +> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de geadresseerde +> bezorgd.* +> www.inbo.be +> +> /////////////////////////////////////////////////////////////////////////////////////////// +> To call in the statistician after the experiment is done may be no more +> than asking him to perform a post-mortem examination: he may be able to say +> what the experiment died of. ~ Sir Ronald Aylmer Fisher +> The plural of anecdote is not data. ~ Roger Brinner +> The combination of some data and an aching desire for an answer does not +> ensure that a reasonable answer can be extracted from a given body of data. +> ~ John Tukey +> /////////////////////////////////////////////////////////////////////////////////////////// +> +> +> +> +> Op ma 6 mei 2024 om 01:59 schreef Srinidhi Jayakumar via R-sig-mixed-models +> : +> +>> I am running a multilevel growth curve model to examine predictors of +>> social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +>> continuous numeric variable. The age variable (Index1) has been coded as 0 +>> for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +>> varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +>> to examine whether trajectory/variation in LSI predicts difference in SA +>> trajectory. LSI is a continuous numeric variable and was grand-mean +>> centered before using in the models. The data has been converted to long +>> format with SA in 1 column, LSI in the other, ID in another, and age in +>> another column. I used the code below to run my model using lmer. However, +>> I get the following error. Please let me know how I can solve this error. +>> Please note that I have 50% missing data in SA at age 12. +>> modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +>> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +>> summary(modelLSI_maineff_RE) +>> Error: number of observations (=1080) <= number of random effects (=1479) +>> for term (1 + Index1 + LSI | ID); the random-effects parameters and the +>> residual variance (or scale parameter) are probably unidentifiable +>> +>> I did test the within-person variance for the LSI variable and the +>> within-person variance is significant from the Greenhouse-Geisser, +>> Hyunh-Feidt tests. +>> +>> I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +>> me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +>> Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +>> "ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +>> "ignore", tol = 1e-4)), REML=TRUE) +>> +>> summary(modelLSI_maineff_RE) +>> Linear mixed model fit by REML. t-tests use Satterthwaite's method +>> ['lmerModLmerTest'] +>> Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +>> Data: LSIDATA +>> Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +>> check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) +>> +>> REML criterion at convergence: 7299.6 +>> +>> Scaled residuals: +>> Min 1Q Median 3Q Max +>> -2.7289 -0.4832 -0.1449 0.3604 4.5715 +>> +>> Random effects: +>> Groups Name Variance Std.Dev. Corr +>> ID (Intercept) 30.2919 5.5038 +>> Index1 2.4765 1.5737 -0.15 +>> LSI 0.1669 0.4085 -0.23 0.70 +>> Residual 24.1793 4.9172 +>> Number of obs: 1080, groups: ID, 493 +>> +>> Fixed effects: +>> Estimate Std. Error df t value Pr(>|t|) +>> (Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +>> Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +>> LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +>> Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +>> Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 +>> +>> Correlation of Fixed Effects: +>> (Intr) Index1 LSI +>> Index1 -0.645 +>> LSI -0.032 0.057 +>> Index1:LSI 0.015 0.037 -0.695 +>> +>> I am a little vary of the output still as the error states that I have +>> equal observations as the number of random effects (i.e., 3 observations +>> per ID and 3 random effects). Hence, I am wondering whether I can simplify +>> the model as either of the below models and choose the one with the +>> best-fit statistics: +>> +>> modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +>> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* +>> +>> modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +>> lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] +>> +>> +>> [[alternative HTML version deleted]] +>> +>> _______________________________________________ +>> R-sig-mixed-models at r-project.org mailing list +>> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +>> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-sig-mixed-models at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models + + + [[alternative HTML version deleted]] + + +From m@ech|er @end|ng |rom @t@t@m@th@ethz@ch Mon May 6 11:10:15 2024 +From: m@ech|er @end|ng |rom @t@t@m@th@ethz@ch (Martin Maechler) +Date: Mon, 6 May 2024 11:10:15 +0200 +Subject: [R] + Get a copy of a matrix only for TRUE entries of a matching size + boolean matrix? +In-Reply-To: +References: + <1fea204c-b71c-4a92-ae13-1dfcf6874357@yahoo.fr> + +Message-ID: <26168.40567.226121.869791@stat.math.ethz.ch> + +>>>>> DynV Montrealer +>>>>> on Fri, 3 May 2024 10:39:10 -0400 writes: + + > It's exactly what I was looking for, thanks. I'm replying + > to the whole list so others can skip this question, to not + > waste time on it. + +good. + + > Bonne fin de journ?e de Montr?al (nous sommes le matin ici) + +Note that the answer Ben Bolker gave you (using "indexing") +is much more efficient than the ifelse() answer below. + +ifelse() may be convenient .. but is almost always suboptimal, +where as "indexing" is typically very often more efficient, +although often requiring a bit more thought than ifelse() +[so, if overall efficience is almost entirely your own human + time, then using ifelse() may still be a good idea... ] + +Martin + + > On Fri, May 3, 2024 at 10:30?AM Marc Girondot wrote: + + >> Is it what you want ? + >> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) + >> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) + >> + >> ifelse(mat_bools, mat_letters, "") + >> ifelse(mat_bools, mat_letters, NA) + >> + >> > ifelse(mat_bools, mat_letters, "") + >> [,1] [,2] + >> [1,] "" "B" + >> [2,] "C" "" + >> > ifelse(mat_bools, mat_letters, NA) + >> [,1] [,2] + >> [1,] NA "B" + >> [2,] "C" NA + >> + >> Marc + >> + >> + >> + >> Le 03/05/2024 ? 14:47, DynV Montrealer a ?crit : + >> + >> Is there a way to get a copy of a matrix only for TRUE entries of a + >> matching size boolean matrix? For **example**: + >> + >> mat_letters <- matrix(data=c('A', 'B', 'C', 'D'), ncol=2, byrow=TRUE) + >> mat_letters + >> + >> [,1] [,2] + >> [1,] "A" "B" + >> [2,] "C" "D" + >> + >> mat_bools <- matrix(data=c(FALSE, TRUE, TRUE, FALSE), ncol=2, byrow=TRUE) + >> mat_bools + >> + >> [,1] [,2] + >> [1,] FALSE TRUE + >> [2,] TRUE FALSE + >> *Reminder:* The following is only an example ; the solution might look very + >> different. + >> some_command(mat_letters, mat_bools, false=empty) + >> [,1] [,2] + >> [1,] "" "B" + >> [2,] "C" "" + >> some_command(mat_letters, mat_bools, false=na) + >> [,1] [,2] + >> [1,] NA "B" + >> [2,] "C" NA + >> + >> + >> + + > [[alternative HTML version deleted]] + + > ______________________________________________ + > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see + > https://stat.ethz.ch/mailman/listinfo/r-help + > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html + > and provide commented, minimal, self-contained, reproducible code. + + +From |kry|ov @end|ng |rom d|@root@org Mon May 6 16:24:25 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Mon, 6 May 2024 17:24:25 +0300 +Subject: [R] + Using intervals() function for nlme model - Statistics Lab ETHZ +In-Reply-To: <9a74d1234c254b40b9a7d5cd119ba08a@student.ethz.ch> +References: <9a74d1234c254b40b9a7d5cd119ba08a@student.ethz.ch> +Message-ID: <20240506172425.7a569ed1@arachnoid> + +Dear Tatiana, Marvin & Paul, + +If you don't get a better answer here, try +r-sig-mixed-models at r-project.org. + +On Fri, 3 May 2024 11:29:19 +0000 +"Bielakova Tatiana" wrote: + +> Based on the documentation of nlme package, the function interval is +> supported for gls, lme, and lmList classes. Although nlme is not +> mentioned, we still receive intervals without any errors or warnings. + +You're right to question this. Programming-language-level inheritance +ends up being backwards for statistical methods: +. +Linear mixed-effect models are a subset of the more general mixed-effect +models, but in R, "nlme" objects inherit from "lme", not the other way +around. + +> * Do you have any other recommendations/ ideas on how should we +> proceed to calculate intervals in R (e.g. more suitable packages)? + +Here's a vignette from the nlraa package where bootstrap is used to get +a confidence interval for an implicit parameter: +https://cran.r-project.org/package=nlraa/vignettes/Bootstrapping.html + +The author seems to be using intervals() on an nlme model without any +problems. It may help to see if the intervals() output agrees with the +bootstrap results from nlraa::boot_nlme(). + +-- +Best regards, +Ivan + + +From |@go@g|ne @end|ng |rom @jd@e@ Tue May 7 11:51:55 2024 +From: |@go@g|ne @end|ng |rom @jd@e@ (=?iso-8859-1?Q?Iago_Gin=E9_V=E1zquez?=) +Date: Tue, 7 May 2024 09:51:55 +0000 +Subject: [R] Is there some way to customize colours for the View output? +Message-ID: + +Hi all, + +As the email subject tells, I write to ask if there is the chance to customize the colours (and in particular the background) of the `View` output window. + + +In the View help, it is told that: + + On Windows, the initial size of the data viewer window is taken from the default dimensions of a pager (see Rconsole), but adjusted downwards to show a whole number of rows and columns. + +So if it works for the sizes, it could work for the colours. But after modifying + +## Colours for console and pager(s) +# (see rwxxxx/etc/rgb.txt for the known colours). +background = gray9 +normaltext = yellow +usertext = YellowGreen +highlight = golderod + +I did not have success. + +On the other hand, in the data.entry it is told that + + The data entry window responds to X resources of class R_dataentry. Resources foreground, background and geometry are utilized. + +But I do not know if this is related and how to modify those resources. + +Can someone help me? + +If this is not possible, is there any chance of making a feature request of this to R-devel? (I mean, I could write to R-devel list, but do you think there would be any interest in developing this?) + +Thanks! +Best regards, + +Iago + + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Tue May 7 12:24:01 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Tue, 7 May 2024 06:24:01 -0400 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: +References: +Message-ID: <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + +If you are using X11, then the paragraph on X resources is relevant. +Create a file named .Xresources in your home directory, and put a line like + +R_dataentry.background: green + +in it. On my Mac, this has to be in place before Xquartz is started. +There is probably a similar restriction on other platforms. + +Colour names (used for foreground and background) can be words or hex +colors like #ffffff . I don't know the format for "geometry", but I'd +guess it's like the -geometry argument to X11 apps, e.g. 1000x1000+0+0. + +If you are on Windows, none of this is relevant. + +Duncan Murdoch + +On 07/05/2024 5:51 a.m., Iago Gin? V?zquez wrote: +> Hi all, +> +> As the email subject tells, I write to ask if there is the chance to customize the colours (and in particular the background) of the `View` output window. +> +> +> In the View help, it is told that: +> +> On Windows, the initial size of the data viewer window is taken from the default dimensions of a pager (see Rconsole), but adjusted downwards to show a whole number of rows and columns. +> +> So if it works for the sizes, it could work for the colours. But after modifying +> +> ## Colours for console and pager(s) +> # (see rwxxxx/etc/rgb.txt for the known colours). +> background = gray9 +> normaltext = yellow +> usertext = YellowGreen +> highlight = golderod +> +> I did not have success. +> +> On the other hand, in the data.entry it is told that +> +> The data entry window responds to X resources of class R_dataentry. Resources foreground, background and geometry are utilized. +> +> But I do not know if this is related and how to modify those resources. +> +> Can someone help me? +> +> If this is not possible, is there any chance of making a feature request of this to R-devel? (I mean, I could write to R-devel list, but do you think there would be any interest in developing this?) +> +> Thanks! +> Best regards, +> +> Iago +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + +From |@go@g|ne @end|ng |rom @jd@e@ Tue May 7 12:31:08 2024 +From: |@go@g|ne @end|ng |rom @jd@e@ (=?iso-8859-1?Q?Iago_Gin=E9_V=E1zquez?=) +Date: Tue, 7 May 2024 10:31:08 +0000 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> +Message-ID: + +Thanks Duncan. + +I am currently on Windows. Is there any solution for it? + +Best regards, +Iago + + +________________________________ +De: Duncan Murdoch +Enviat el: dimarts, 7 de maig de 2024 12:24 +Per a: Iago Gin? V?zquez ; r-help at r-project.org +Tema: Re: [R] Is there some way to customize colours for the View output? + +If you are using X11, then the paragraph on X resources is relevant. +Create a file named .Xresources in your home directory, and put a line like + +R_dataentry.background: green + +in it. On my Mac, this has to be in place before Xquartz is started. +There is probably a similar restriction on other platforms. + +Colour names (used for foreground and background) can be words or hex +colors like #ffffff . I don't know the format for "geometry", but I'd +guess it's like the -geometry argument to X11 apps, e.g. 1000x1000+0+0. + +If you are on Windows, none of this is relevant. + +Duncan Murdoch + +On 07/05/2024 5:51 a.m., Iago Gin? V?zquez wrote: +> Hi all, +> +> As the email subject tells, I write to ask if there is the chance to customize the colours (and in particular the background) of the `View` output window. +> +> +> In the View help, it is told that: +> +> On Windows, the initial size of the data viewer window is taken from the default dimensions of a pager (see Rconsole), but adjusted downwards to show a whole number of rows and columns. +> +> So if it works for the sizes, it could work for the colours. But after modifying +> +> ## Colours for console and pager(s) +> # (see rwxxxx/etc/rgb.txt for the known colours). +> background = gray9 +> normaltext = yellow +> usertext = YellowGreen +> highlight = golderod +> +> I did not have success. +> +> On the other hand, in the data.entry it is told that +> +> The data entry window responds to X resources of class R_dataentry. Resources foreground, background and geometry are utilized. +> +> But I do not know if this is related and how to modify those resources. +> +> Can someone help me? +> +> If this is not possible, is there any chance of making a feature request of this to R-devel? (I mean, I could write to R-devel list, but do you think there would be any interest in developing this?) +> +> Thanks! +> Best regards, +> +> Iago +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Tue May 7 12:34:50 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Tue, 7 May 2024 06:34:50 -0400 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + +Message-ID: <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> + +On 07/05/2024 6:31 a.m., Iago Gin? V?zquez wrote: +> Thanks Duncan. +> +> I am currently on Windows. Is there any solution for it? + +Switch to Linux or MacOS? + +Duncan Murdoch + +> +> Best regards, +> Iago +> +> +> ------------------------------------------------------------------------ +> *De:* Duncan Murdoch +> *Enviat el:* dimarts, 7 de maig de 2024 12:24 +> *Per a:* Iago Gin? V?zquez ; r-help at r-project.org +> +> *Tema:* Re: [R] Is there some way to customize colours for the View output? +> If you are using X11, then the paragraph on X resources is relevant. +> Create a file named .Xresources in your home directory, and put a line like +> +> R_dataentry.background: green +> +> in it.? On my Mac, this has to be in place before Xquartz is started. +> There is probably a similar restriction on other platforms. +> +> Colour names (used for foreground and background) can be words or hex +> colors like #ffffff .? I don't know the format for "geometry", but I'd +> guess it's like the -geometry argument to X11 apps, e.g. 1000x1000+0+0. +> +> If you are on Windows, none of this is relevant. +> +> Duncan Murdoch +> +> On 07/05/2024 5:51 a.m., Iago Gin? V?zquez wrote: +>> Hi all, +>> +>> As the email subject tells, I write to ask if there is the chance to customize the colours (and in particular the background) of the `View` output window. +>> +>> +>> In the View help, it is told that: +>> +>>????? On Windows, the initial size of the data viewer window is taken from the default dimensions of a pager (see Rconsole), but adjusted downwards to show a whole number of rows and columns. +>> +>> So if it works for the sizes, it could work for the colours. But after modifying +>> +>> ## Colours for console and pager(s) +>> # (see rwxxxx/etc/rgb.txt for the known colours). +>> background = gray9 +>> normaltext = yellow +>> usertext = YellowGreen +>> highlight = golderod +>> +>> I did not have success. +>> +>> On the other hand, in the data.entry it is told that +>> +>>????? The data entry window responds to X resources of class R_dataentry. Resources foreground, background and geometry are utilized. +>> +>> But I do not know if this is related and how to modify those resources. +>> +>> Can someone help me? +>> +>> If this is not possible, is there any chance of making a feature request of this to R-devel? (I mean, I could write to R-devel list, but do you think there would be any interest in developing this?) +>> +>> Thanks! +>> Best regards, +>> +>> Iago +>> +>>??????? [[alternative HTML version deleted]] +>> +>> ______________________________________________ +>> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +>> https://stat.ethz.ch/mailman/listinfo/r-help +> +>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> +>> and provide commented, minimal, self-contained, reproducible code. +> + + +From |kry|ov @end|ng |rom d|@root@org Tue May 7 13:56:02 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Tue, 7 May 2024 14:56:02 +0300 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: +References: +Message-ID: <20240507145602.14dd1e01@arachnoid> + +? Tue, 7 May 2024 09:51:55 +0000 +Iago Gin? V?zquez ?????: + +> In the View help, it is told that: +> +> On Windows, the initial size of the data viewer window is taken +> from the default dimensions of a pager (see Rconsole), but adjusted +> downwards to show a whole number of rows and columns. + +The Windows data editor lives in +src/library/utils/src/windows/dataentry.c [1]. There are references to +the array guiColors and indices dataeditbg, dataedituser, dataeditbg, +dataeditfg. I was able to find the colours with these names in the GUI +preferences, edit them and see an effect on the edit() window. + +-- +Best regards, +Ivan + +[1] +https://svn.r-project.org/R/trunk/src/library/utils/src/windows/dataentry.c + + +From gdu|ey @end|ng |rom gm@||@com Tue May 7 16:57:14 2024 +From: gdu|ey @end|ng |rom gm@||@com (gavin duley) +Date: Tue, 7 May 2024 16:57:14 +0200 +Subject: [R] Problem with creating a PCA graph in a loop +Message-ID: + +Hi all, + +I am having enormous problems with a loop that iterates over different +levels in the factor wine.data$Time (levels T06, T09, and T12) and +creates a PCA and graph for individuals at that time only. These +graphs need to be accessible outside the loop, so I can combine them +using ggpubr::ggarrange to produce a figure for a paper. + +The difficulty I am having is with the labels produced by +ggrepel::geom_label_repel. Since the loop uses the variable i to set +the level of wine.data$Time, when used outside the loop the labels +produced by geom_label_repel are always for T12 (i.e., the last level +run by the loop). + +Oddly, this only affects the labels: the title, set using +ggtitle(paste0("PCA of wine.data observations at Time ", print(i))), +shows the correct time, and the datapoints are for the correct time. + +Is there some way to get geom_label_repel to read current_rownames and +store the values in the ggplot object, rather than to reload them +every time I display or save the ggplot graph? + +Thanks! +gavin, + +Code for reference. I can provide a sample dataset for reproducibility +if needed. + +for(i in levels(wine.data$Time)){ + print(i) + wine.data.filt <- filter(wine.data,Time == i) + current_rownames <- rownames(wine.data.filt) + wine.data.filt.pca <- dudi.pca(wine.data.filt[3:11], + nf=6, + scannf=F) + wine.data_quanti_sup <- wine.data.filt[,12, drop = FALSE] + head(wine.data_quanti_sup) + + # Colour by Treatment + assign(paste0("individ_", i), + fviz_pca_ind(wine.data.filt.pca, + geom.ind = "point", + mean.point=F, + col.ind = wine.data.filt$Treatment, + ellipse.type = "confidence", + legend.title = "Groups" + )+ggtitle(paste0("PCA of wine.data observations at Time ", print(i))) + + + scale_colour_manual( + values = c( + "Control" = "#00A087FF", + "Low" = "#3C5488FF", + "High" = "#E64B35FF") + ) + geom_label_repel(position = +ggpp::position_nudge_center(0.2, 0.1, 0, 0), + box.padding = 0.5, + max.overlaps = Inf, + aes(label=current_rownames, + colour=wine.data.filt$Treatment + ) + ) + + scale_fill_manual( + values = c( + "Control" = "#00A087FF", + "Low" = "#3C5488FF", + "High" = "#E64B35FF") + )) +} + + +From @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu Mon May 6 15:53:30 2024 +From: @r|n|dh|@j@y@kum@r @end|ng |rom @tonybrook@edu (Srinidhi Jayakumar) +Date: Mon, 6 May 2024 09:53:30 -0400 +Subject: [R] [R-sig-ME] lmer error: number of observations <= number of + random effects +In-Reply-To: +References: + + +Message-ID: + +Thank you very much for your responses! + +What if I reduce the model to + modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +lmerControl(optimizer ="bobyqa"), REML=TRUE). +This would allow me to see the random effects of LSI and I can drop the +random effect of age (Index1) since I can see that in the unconditional +model [model0 <- lmer(SA ~ Index1+ (1+Index1|ID),data = LSIDATA, control = +lmerControl(optimizer ="bobyqa"), REML=TRUE)]. Would the modelLSI3 also +have a type 1 error? + +Thank you, +Srinidhi + + + + +On Mon, 6 May 2024, 03:11 TT FF, wrote: + +> See if this paper may help If it helps reducing the model when you have +> few observations. the (1|ID) may increase the type 1 error. +> https://journals.sagepub.com/doi/10.1177/25152459231214454 +> +> Best +> +> On 6 May 2024, at 07:45, Thierry Onkelinx via R-sig-mixed-models < +> r-sig-mixed-models at r-project.org> wrote: +> +> Dear Srinidhi, +> +> You are trying to fit 1 random intercept and 2 random slopes per +> individual, while you have at most 3 observations per individual. You +> simply don't have enough data to fit the random slopes. Reduce the random +> part to (1|ID). +> +> Best regards, +> +> Thierry +> +> ir. Thierry Onkelinx +> Statisticus / Statistician +> +> Vlaamse Overheid / Government of Flanders +> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND +> FOREST +> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +> thierry.onkelinx at inbo.be +> Havenlaan 88 bus 73, 1000 Brussel +> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +> *Poststukken die naar dit adres worden gestuurd, worden ingescand en +> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +> dossiers volledig digitaal behandelen. Poststukken met de vermelding +> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de geadresseerde +> bezorgd.* +> www.inbo.be +> +> +> /////////////////////////////////////////////////////////////////////////////////////////// +> To call in the statistician after the experiment is done may be no more +> than asking him to perform a post-mortem examination: he may be able to say +> what the experiment died of. ~ Sir Ronald Aylmer Fisher +> The plural of anecdote is not data. ~ Roger Brinner +> The combination of some data and an aching desire for an answer does not +> ensure that a reasonable answer can be extracted from a given body of data. +> ~ John Tukey +> +> /////////////////////////////////////////////////////////////////////////////////////////// +> +> +> +> +> Op ma 6 mei 2024 om 01:59 schreef Srinidhi Jayakumar via R-sig-mixed-models +> : +> +> I am running a multilevel growth curve model to examine predictors of +> social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +> continuous numeric variable. The age variable (Index1) has been coded as 0 +> for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +> varying predictor, stress (LSI), which was measured at ages 12, 15 and 18, +> to examine whether trajectory/variation in LSI predicts difference in SA +> trajectory. LSI is a continuous numeric variable and was grand-mean +> centered before using in the models. The data has been converted to long +> format with SA in 1 column, LSI in the other, ID in another, and age in +> another column. I used the code below to run my model using lmer. However, +> I get the following error. Please let me know how I can solve this error. +> Please note that I have 50% missing data in SA at age 12. +> modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +> summary(modelLSI_maineff_RE) +> Error: number of observations (=1080) <= number of random effects (=1479) +> for term (1 + Index1 + LSI | ID); the random-effects parameters and the +> residual variance (or scale parameter) are probably unidentifiable +> +> I did test the within-person variance for the LSI variable and the +> within-person variance is significant from the Greenhouse-Geisser, +> Hyunh-Feidt tests. +> +> I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which gave +> me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + +> Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE = +> "ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +> "ignore", tol = 1e-4)), REML=TRUE) +> +> summary(modelLSI_maineff_RE) +> Linear mixed model fit by REML. t-tests use Satterthwaite's method +> ['lmerModLmerTest'] +> Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +> Data: LSIDATA +> Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +> check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) +> +> REML criterion at convergence: 7299.6 +> +> Scaled residuals: +> Min 1Q Median 3Q Max +> -2.7289 -0.4832 -0.1449 0.3604 4.5715 +> +> Random effects: +> Groups Name Variance Std.Dev. Corr +> ID (Intercept) 30.2919 5.5038 +> Index1 2.4765 1.5737 -0.15 +> LSI 0.1669 0.4085 -0.23 0.70 +> Residual 24.1793 4.9172 +> Number of obs: 1080, groups: ID, 493 +> +> Fixed effects: +> Estimate Std. Error df t value Pr(>|t|) +> (Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +> Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +> LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +> Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +> Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 +> +> Correlation of Fixed Effects: +> (Intr) Index1 LSI +> Index1 -0.645 +> LSI -0.032 0.057 +> Index1:LSI 0.015 0.037 -0.695 +> +> I am a little vary of the output still as the error states that I have +> equal observations as the number of random effects (i.e., 3 observations +> per ID and 3 random effects). Hence, I am wondering whether I can simplify +> the model as either of the below models and choose the one with the +> best-fit statistics: +> +> modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +> LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* +> +> modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +> lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-sig-mixed-models at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-sig-mixed-models at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> +> +> + + [[alternative HTML version deleted]] + + +From bgunter@4567 @end|ng |rom gm@||@com Tue May 7 19:23:48 2024 +From: bgunter@4567 @end|ng |rom gm@||@com (Bert Gunter) +Date: Tue, 7 May 2024 10:23:48 -0700 +Subject: [R] [R-sig-ME] lmer error: number of observations <= number of + random effects +In-Reply-To: +References: + + + +Message-ID: + +I think you should seek out a local statistician with whom to consult if at +all possible, as the details of your research goals and the nature of the +data you have to meet those goals matter and cannot be effectively +discussed in a remote forum like this. That is, to be blunt, you seem to be +risk of producing junk. Just my opinion, which you are of course free to +ignore. Certainly, no response needed, and I will not say anything further. + +Cheers, +Bert + +On Tue, May 7, 2024 at 9:12?AM Srinidhi Jayakumar via R-help < +r-help at r-project.org> wrote: + +> Thank you very much for your responses! +> +> What if I reduce the model to +> modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +> lmerControl(optimizer ="bobyqa"), REML=TRUE). +> This would allow me to see the random effects of LSI and I can drop the +> random effect of age (Index1) since I can see that in the unconditional +> model [model0 <- lmer(SA ~ Index1+ (1+Index1|ID),data = LSIDATA, control = +> lmerControl(optimizer ="bobyqa"), REML=TRUE)]. Would the modelLSI3 also +> have a type 1 error? +> +> Thank you, +> Srinidhi +> +> +> +> +> On Mon, 6 May 2024, 03:11 TT FF, wrote: +> +> > See if this paper may help If it helps reducing the model when you have +> > few observations. the (1|ID) may increase the type 1 error. +> > https://journals.sagepub.com/doi/10.1177/25152459231214454 +> > +> > Best +> > +> > On 6 May 2024, at 07:45, Thierry Onkelinx via R-sig-mixed-models < +> > r-sig-mixed-models at r-project.org> wrote: +> > +> > Dear Srinidhi, +> > +> > You are trying to fit 1 random intercept and 2 random slopes per +> > individual, while you have at most 3 observations per individual. You +> > simply don't have enough data to fit the random slopes. Reduce the random +> > part to (1|ID). +> > +> > Best regards, +> > +> > Thierry +> > +> > ir. Thierry Onkelinx +> > Statisticus / Statistician +> > +> > Vlaamse Overheid / Government of Flanders +> > INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE +> AND +> > FOREST +> > Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +> > thierry.onkelinx at inbo.be +> > Havenlaan 88 bus 73, 1000 Brussel +> > *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +> > *Poststukken die naar dit adres worden gestuurd, worden ingescand en +> > digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +> > dossiers volledig digitaal behandelen. Poststukken met de vermelding +> > ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de +> geadresseerde +> > bezorgd.* +> > www.inbo.be +> > +> > +> > +> /////////////////////////////////////////////////////////////////////////////////////////// +> > To call in the statistician after the experiment is done may be no more +> > than asking him to perform a post-mortem examination: he may be able to +> say +> > what the experiment died of. ~ Sir Ronald Aylmer Fisher +> > The plural of anecdote is not data. ~ Roger Brinner +> > The combination of some data and an aching desire for an answer does not +> > ensure that a reasonable answer can be extracted from a given body of +> data. +> > ~ John Tukey +> > +> > +> /////////////////////////////////////////////////////////////////////////////////////////// +> > +> > +> > +> > +> > Op ma 6 mei 2024 om 01:59 schreef Srinidhi Jayakumar via +> R-sig-mixed-models +> > : +> > +> > I am running a multilevel growth curve model to examine predictors of +> > social anhedonia (SA) trajectory through ages 12, 15 and 18. SA is a +> > continuous numeric variable. The age variable (Index1) has been coded as +> 0 +> > for age 12, 1 for age 15 and 2 for age 18. I am currently using a time +> > varying predictor, stress (LSI), which was measured at ages 12, 15 and +> 18, +> > to examine whether trajectory/variation in LSI predicts difference in SA +> > trajectory. LSI is a continuous numeric variable and was grand-mean +> > centered before using in the models. The data has been converted to long +> > format with SA in 1 column, LSI in the other, ID in another, and age in +> > another column. I used the code below to run my model using lmer. +> However, +> > I get the following error. Please let me know how I can solve this error. +> > Please note that I have 50% missing data in SA at age 12. +> > modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ (1 + Index1+LSI |ID), data +> = +> > LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) +> > summary(modelLSI_maineff_RE) +> > Error: number of observations (=1080) <= number of random effects (=1479) +> > for term (1 + Index1 + LSI | ID); the random-effects parameters and the +> > residual variance (or scale parameter) are probably unidentifiable +> > +> > I did test the within-person variance for the LSI variable and the +> > within-person variance is significant from the Greenhouse-Geisser, +> > Hyunh-Feidt tests. +> > +> > I also tried control = lmerControl(check.nobs.vs.nRE = "ignore") which +> gave +> > me the following output. modelLSI_maineff_RE <- lmer(SA ~ Index1* LSI+ +> (1 + +> > Index1+LSI |ID), data = LSIDATA, control = lmerControl(check.nobs.vs.nRE +> = +> > "ignore", optimizer ="bobyqa", check.conv.singular = .makeCC(action = +> > "ignore", tol = 1e-4)), REML=TRUE) +> > +> > summary(modelLSI_maineff_RE) +> > Linear mixed model fit by REML. t-tests use Satterthwaite's method +> > ['lmerModLmerTest'] +> > Formula: SA ~ Index1 * LSI + (1 + Index1 + LSI | ID) +> > Data: LSIDATA +> > Control: lmerControl(check.nobs.vs.nRE = "ignore", optimizer = "bobyqa", +> > check.conv.singular = .makeCC(action = "ignore", tol = 1e-04)) +> > +> > REML criterion at convergence: 7299.6 +> > +> > Scaled residuals: +> > Min 1Q Median 3Q Max +> > -2.7289 -0.4832 -0.1449 0.3604 4.5715 +> > +> > Random effects: +> > Groups Name Variance Std.Dev. Corr +> > ID (Intercept) 30.2919 5.5038 +> > Index1 2.4765 1.5737 -0.15 +> > LSI 0.1669 0.4085 -0.23 0.70 +> > Residual 24.1793 4.9172 +> > Number of obs: 1080, groups: ID, 493 +> > +> > Fixed effects: +> > Estimate Std. Error df t value Pr(>|t|) +> > (Intercept) 24.68016 0.39722 313.43436 62.133 < 2e-16 *** +> > Index1 0.98495 0.23626 362.75018 4.169 3.83e-05 *** +> > LSI -0.05197 0.06226 273.85575 -0.835 0.4046 +> > Index1:LSI 0.09797 0.04506 426.01185 2.174 0.0302 * +> > Signif. codes: 0 ?? 0.001 ?? 0.01 ?? 0.05 ?.? 0.1 ? ? 1 +> > +> > Correlation of Fixed Effects: +> > (Intr) Index1 LSI +> > Index1 -0.645 +> > LSI -0.032 0.057 +> > Index1:LSI 0.015 0.037 -0.695 +> > +> > I am a little vary of the output still as the error states that I have +> > equal observations as the number of random effects (i.e., 3 observations +> > per ID and 3 random effects). Hence, I am wondering whether I can +> simplify +> > the model as either of the below models and choose the one with the +> > best-fit statistics: +> > +> > modelLSI2 <- lmer(SA ~ Index1* LSI+ (1 |ID)+ (Index1+LSI -1|ID),data = +> > LSIDATA, control = lmerControl(optimizer ="bobyqa"), REML=TRUE) *OR* +> > +> > modelLSI3 <- lmer(SA ~ Index1* LSI+ (1+LSI |ID),data = LSIDATA, control = +> > lmerControl(optimizer ="bobyqa"), REML=TRUE) [image: example of dataset] +> > +> > +> > [[alternative HTML version deleted]] +> > +> > _______________________________________________ +> > R-sig-mixed-models at r-project.org mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> > +> > +> > [[alternative HTML version deleted]] +> > +> > _______________________________________________ +> > R-sig-mixed-models at r-project.org mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-sig-mixed-models +> > +> > +> > +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide +> http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. +> + + [[alternative HTML version deleted]] + + +From ro||turner @end|ng |rom po@teo@net Tue May 7 23:58:32 2024 +From: ro||turner @end|ng |rom po@teo@net (Rolf Turner) +Date: Tue, 7 May 2024 21:58:32 +0000 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + + <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> +Message-ID: <20240508095832.7886e41c@rolf-Latitude-E7470> + + +On Tue, 7 May 2024 06:34:50 -0400 +Duncan Murdoch wrote: + +> On 07/05/2024 6:31 a.m., Iago Gin? V?zquez wrote: +> > Thanks Duncan. +> > +> > I am currently on Windows. Is there any solution for it? +> +> Switch to Linux or MacOS? + + +Fortune nomination! + +cheers, + +Rolf Turner + +-- +Honorary Research Fellow +Department of Statistics +University of Auckland +Stats. Dep't. (secretaries) phone: + +64-9-373-7599 ext. 89622 +Home phone: +64-9-480-4619 + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 09:16:38 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 10:16:38 +0300 +Subject: [R] Problem with creating a PCA graph in a loop +In-Reply-To: +References: +Message-ID: <20240508101638.630564b1@Tarkus> + +? Tue, 7 May 2024 16:57:14 +0200 +gavin duley ?????: + +> aes(label=current_rownames, +> colour=wine.data.filt$Treatment +> ) + +As you've noticed, aes() remembers variables by their name and +environment, not by value: + +str(ggplot2::aes(label = foo)) +# List of 1 +# $ label: language ~foo # <-- variable name recorded here + # and here is the environment +# ..- attr(*, ".Environment")= +# - attr(*, "class")= chr "uneval" + +One way to get around the problem is to ensure that the variables live +in different environments. Instead of making it a for loop, write a +function that would accept `i` and return a plot instead of assigning +it by name: + +makeplot <- function(i) { + print(i) + wine.data.filt <- filter(wine.data,Time == i) + current_rownames <- rownames(wine.data.filt) + wine.data.filt.pca <- dudi.pca(wine.data.filt[3:11], + nf=6, + scannf=F) + wine.data_quanti_sup <- wine.data.filt[,12, drop = FALSE] + return(fviz_pca_ind(wine.data.filt.pca, + # + ) +} + +individs <- lapply(levels(wine.data$Time), makeplot) +individs[[1]] + +(In many languages, trying to use a variable as a variable name, while +possible, usually means you need to consider some kind of nested data +structure: +https://perldoc.perl.org/perlfaq7#How-can-I-use-a-variable-as-a-variable-name? +In R, this structure is a list.) + +Why does this work? Calling a function creates a new environment every +time. The plots will all refer to the variable named current_rownames, +but the environments will be different: + +attr((function() ggplot2::aes(label = foo))()$label, '.Environment') +# +attr((function() ggplot2::aes(label = foo))()$label, '.Environment') +# +attr((function() ggplot2::aes(label = foo))()$label, '.Environment') +# + +Alternatively, supply a data= argument to geom_label_repel() and make +your mapping = aes(...) reference variables from the data (which will +be remembered), ignoring the environment (which is only referenced). +Something like the following should work, untested: + +geom_label_repel( + mapping = aes(label = current_rownames, colour = Treatment), + data = data.frame( + current_rownames = current_rownames, + Treatment = wine.data.filt$Treatment + ), + # more arguments here +) + +-- +Best regards, +Ivan + + +From v|to@muggeo @end|ng |rom un|p@@|t Wed May 8 13:47:28 2024 +From: v|to@muggeo @end|ng |rom un|p@@|t (Vito Muggeo) +Date: Wed, 8 May 2024 13:47:28 +0200 +Subject: [R] losing variable attributes when subsetting model.frame +Message-ID: <2577c082-7240-4ce5-a082-43030d54992c@unipa.it> + +dear all, +I have a simple function f() which, when included in model.frame() via +the formula, returns the variable itself with some attributes. +However when I specify the subset argument, the attributes get lost, +apparently. + +I would like to extract the attributes also when specifying the subset +argument. Of course, I can build the whole dataframe without subsetting, +taking the attributes and then build again the dataframe with 'subset', +but I am wondering if a more direct (and elegant) solution exists. + +Any suggestion? +Thank you very much, +best, +Vito + + +#============================= +Here a simple example.. + +f<- function(x){ + attr(x,"vi")<-length(x) + x +} + +x<- 1:5 +z<-runif(5) +y<-rnorm(5) + +mf<- model.frame(y~f(z)) +attr(mf[,2],"vi") #it works + + +mf <- model.frame(y~f(z), subset=x>=3) +attr(mf[,2],"vi") #it does not work + + + + +-- +================================================= +Vito M.R. Muggeo, PhD +Professor of Statistics +Dip.to Sc Econom, Az e Statistiche +Universit? di Palermo +viale delle Scienze, edificio 13 +90128 Palermo - ITALY +tel: 091 23895240; fax: 091 485726 +http://www.unipa.it/persone/docenti/m/vito.muggeo +Assoc Editor: Statist Modelling +past chair, Statistical Modelling Society +coordinator, PhD Program in Econ, Businss, Statist + + +From murdoch@dunc@n @end|ng |rom gm@||@com Wed May 8 14:06:06 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Wed, 8 May 2024 08:06:06 -0400 +Subject: [R] losing variable attributes when subsetting model.frame +In-Reply-To: <2577c082-7240-4ce5-a082-43030d54992c@unipa.it> +References: <2577c082-7240-4ce5-a082-43030d54992c@unipa.it> +Message-ID: <900af347-30a6-4f1c-8b32-f56feb09cd27@gmail.com> + +On 08/05/2024 7:47 a.m., Vito Muggeo via R-help wrote: +> dear all, +> I have a simple function f() which, when included in model.frame() via +> the formula, returns the variable itself with some attributes. +> However when I specify the subset argument, the attributes get lost, +> apparently. +> +> I would like to extract the attributes also when specifying the subset +> argument. Of course, I can build the whole dataframe without subsetting, +> taking the attributes and then build again the dataframe with 'subset', +> but I am wondering if a more direct (and elegant) solution exists. +> +> Any suggestion? +> Thank you very much, +> best, +> Vito +> +> +> #============================= +> Here a simple example.. +> +> f<- function(x){ +> attr(x,"vi")<-length(x) +> x +> } +> +> x<- 1:5 +> z<-runif(5) +> y<-rnorm(5) +> +> mf<- model.frame(y~f(z)) +> attr(mf[,2],"vi") #it works +> +> +> mf <- model.frame(y~f(z), subset=x>=3) +> attr(mf[,2],"vi") #it does not work +> + +I would guess that subsetting uses [] indexing on each column, with a +logical argument. If that is true, then one solution (which is less +direct, but maybe someone would call it elegant) is to put a class on +the result of `f()`, and define a `[` method for that class that +preserves the attributes you want to preserve. + +In your example: + +f <- function(x) { + attr(x, "vi") <- length(x) + class(x) <- c("withAttributes", class(x)) + x +} + +`[.withAttributes` <- function(x, i) { + subset <- NextMethod() + attr(subset, "vi") <- attr(x, "vi") + subset +} + + +x<- 1:5 +z<-runif(5) +y<-rnorm(5) + +mf <- model.frame(y~f(z), subset=x>=3) +attr(mf[,2],"vi") #it works +#> [1] 5 + +Duncan Murdoch + + +From v|to@muggeo @end|ng |rom un|p@@|t Wed May 8 14:57:54 2024 +From: v|to@muggeo @end|ng |rom un|p@@|t (Vito Muggeo) +Date: Wed, 8 May 2024 14:57:54 +0200 +Subject: [R] losing variable attributes when subsetting model.frame +In-Reply-To: <900af347-30a6-4f1c-8b32-f56feb09cd27@gmail.com> +References: <2577c082-7240-4ce5-a082-43030d54992c@unipa.it> + <900af347-30a6-4f1c-8b32-f56feb09cd27@gmail.com> +Message-ID: <439561a0-3454-4cae-9bfc-c6aa66d132fa@unipa.it> + +dear Duncan, +Thank you very much for your quick reply. Very useful and also very +elegant, I would add. + +Thanks again, +kind regards, + +Vito + + +Il 08/05/2024 14:06, Duncan Murdoch ha scritto: +> I would guess that subsetting uses [] indexing on each column, with a +> logical argument.? If that is true, then one solution (which is less +> direct, but maybe someone would call it elegant) is to put a class on +> the result of `f()`, and define a `[` method for that class that +> preserves the attributes you want to preserve. +> +> In your example: +> +> f <- function(x) { +> ? attr(x, "vi") <- length(x) +> ? class(x) <- c("withAttributes", class(x)) +> ? x +> } +> +> `[.withAttributes` <- function(x, i) { +> ? subset <- NextMethod() +> ? attr(subset, "vi") <- attr(x, "vi") +> ? subset +> } +> +> +> x<- 1:5 +> z<-runif(5) +> y<-rnorm(5) +> +> mf <- model.frame(y~f(z), subset=x>=3) +> attr(mf[,2],"vi") #it works +> #> [1] 5 + +-- +================================================= +Vito M.R. Muggeo, PhD +Professor of Statistics +Dip.to Sc Econom, Az e Statistiche +Universit? di Palermo +viale delle Scienze, edificio 13 +90128 Palermo - ITALY +tel: 091 23895240; fax: 091 485726 +http://www.unipa.it/persone/docenti/m/vito.muggeo +Assoc Editor: Statist Modelling, Statist Meth Appl +past chair, Statistical Modelling Society +coordinator, PhD Program in Econ, Businss, Statist + + +From @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk Wed May 8 12:17:41 2024 +From: @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk (Simon Andrews) +Date: Wed, 8 May 2024 10:17:41 +0000 +Subject: [R] Compilation problems with R4.4.0 +Message-ID: + +I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box. I've compiled previous versions OK on the same hardware/software (last was R4.3.2) but 4.4.0 is repeatedly failing. + +Configuration works OK. + +./configure --prefix=/bi/apps/R/4.4.0 --enable-R-shlib + +R is now configured for x86_64-pc-linux-gnu + + Source directory: . + Installation directory: /bi/apps/R/4.4.0 + + C compiler: gcc -g -O2 + Fortran fixed-form compiler: gfortran -g -O2 + + Default C++ compiler: g++ -std=gnu++17 -g -O2 + C++11 compiler: g++ -std=gnu++11 -g -O2 + C++14 compiler: g++ -std=gnu++14 -g -O2 + C++17 compiler: g++ -std=gnu++17 -g -O2 + C++20 compiler: g++ -std=gnu++20 -g -O2 + C++23 compiler: g++ -std=gnu++23 -g -O2 + Fortran free-form compiler: gfortran -g -O2 + Obj-C compiler: + + Interfaces supported: X11 + External libraries: pcre2, readline, LAPACK(generic), curl + Additional capabilities: PNG, JPEG, TIFF, NLS, cairo, ICU + Options enabled: shared R library, shared BLAS, R profiling + + Capabilities skipped: + Options not enabled: memory profiling + + Recommended packages: yes + +configure: WARNING: neither inconsolata.sty nor zi4.sty found: PDF vignettes and package manuals will not be rendered optimally +configure: WARNING: I could not determine a browser +configure: WARNING: I could not determine a PDF viewer + +..but after running make it gets though most of it then dies with: + +make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices' +byte-compiling package 'grDevices' + +*** caught segfault *** +address 0x18017a8110, cause 'memory not mapped' + +Traceback: +1: solve.default(rgb) +2: solve(rgb) +3: drop(whitexyz %*% solve(rgb)) +4: make.rgb(red = c(0.625, 0.34), green = c(0.28, 0.595), blue = c(0.155, 0.07), gamma = 1.8, white = "D65", name = "Apple RGB") +5: eval(exprs[i], envir) +6: eval(exprs[i], envir) +7: sys.source(codeFile, env, keep.source = keep.source, keep.parse.data = keep.parse.data) +8: doTryCatch(return(expr), name, parentenv, handler) +9: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +10: tryCatchList(expr, classes, parentenv, handlers) +11: tryCatch(expr, error = function(e) { call <- conditionCall(e) if (!is.null(call)) { if (identical(call[[1L]], quote(doTryCatch))) call <- sys.call(-4L) dcall <- deparse(call, nlines = 1L) prefix <- paste("Error in", dcall, ": ") LONG <- 75L sm <- strsplit(conditionMessage(e), "\n")[[1L]] w <- 14L + nchar(dcall, type = "w") + nchar(sm[1L], type = "w") if (is.na(w)) w <- 14L + nchar(dcall, type = "b") + nchar(sm[1L], type = "b") if (w > LONG) prefix <- paste0(prefix, "\n ") } else prefix <- "Error : " msg <- paste0(prefix, conditionMessage(e), "\n") .Internal(seterrmessage(msg[1L])) if (!silent && isTRUE(getOption("show.error.messages"))) { cat(msg, file = outFile) .Internal(printDeferredWarnings()) } invisible(structure(msg, class = "try-error", condition = e))}) +12: try(sys.source(codeFile, env, keep.source = keep.source, keep.parse.data = keep.parse.data)) +13: loadNamespace(package = package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, partial = TRUE) +14: withCallingHandlers(expr, packageStartupMessage = function(c) tryInvokeRestart("muffleMessage")) +15: suppressPackageStartupMessages(loadNamespace(package = package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, partial = TRUE)) +16: code2LazyLoadDB(package, lib.loc = lib.loc, keep.source = keep.source, keep.parse.data = keep.parse.data, compress = compress, set.install.dir = set.install.dir) +17: tools:::makeLazyLoading("grDevices") +An irrecoverable exception occurred. R is aborting now ... +make[4]: *** [../../../share/make/lazycomp.mk:9: ../../../library/grDevices/R/grDevices.rdb] Error 139 + +I can reproduce the error directly by running make in /bi/apps/R/R-4.4.0/src/library/grDevices. Nothing strange is in my environment, I'm using the stock version of make and gcc + +$ which make +/usr/bin/make +$ which gcc +/usr/bin/gcc + +$ make --version +GNU Make 4.3 +Built for x86_64-redhat-linux-gnu + +$ gcc --version +gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2) + + +I can't find any other instances of others hitting the same problem. + +Any suggestions for what this could be? + +Thanks + +Simon. + + + + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 16:12:28 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 17:12:28 +0300 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: +References: +Message-ID: <20240508171228.0b2d930e@arachnoid> + +Dear Simon, + +? Wed, 8 May 2024 10:17:41 +0000 +Simon Andrews via R-help ?????: + +> I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box. + +> make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices' +> byte-compiling package 'grDevices' +> +> *** caught segfault *** +> address 0x18017a8110, cause 'memory not mapped' +> +> Traceback: +> 1: solve.default(rgb) + +Miguel Esteva has recently complained about the same problem on RHEL9, +but didn't provide enough details, nor was I able to reproduce it +myself: https://stat.ethz.ch/pipermail/r-help/2024-May/479288.html + +Thanks for letting us know it's reproducible on AlmaLinux and telling +us your compiler version! + +Unfortunately, I wasn't able to reproduce the crash, neither with +gcc-toolset-13, nor with the ordinary gcc & gfortran 11.4.1 20231218 +(Red Hat 11.4.1-3) from the repository. I see that your compiler version +is slightly different (11.4.1-2). I'm running `podman run -it --rm +almalinux:9`. Would an upgrade help? + +Can you run R under the debugger and obtain a backtrace? Something like +the following, in the src/library/grDevices subdirectory: + +_R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 \ + R_DEFAULT_PACKAGES=NULL LC_ALL=C \ +../../../bin/R -d gdb --vanilla --no-echo -e \ + 'tools:::makeLazyLoading("grDevices")' + +-- +Best regards, +Ivan + + +From @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk Wed May 8 16:25:08 2024 +From: @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk (Simon Andrews) +Date: Wed, 8 May 2024 14:25:08 +0000 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: <20240508171228.0b2d930e@arachnoid> +References: + <20240508171228.0b2d930e@arachnoid> +Message-ID: + +Hi Ivan, + +Thanks for getting back to me and very happy to hear I'm not the only one who's seen this. + +I've run the command under the debugger and the backtrace is below. It's complaining about missing debuginfo packages, but I definitely installed them so I'm not sure why they're not being seen. + +$ ./debug.sh +GNU gdb (GDB) Red Hat Enterprise Linux 10.2-11.el9 +Copyright (C) 2021 Free Software Foundation, Inc. +License GPLv3+: GNU GPL version 3 or later +This is free software: you are free to change and redistribute it. +There is NO WARRANTY, to the extent permitted by law. +Type "show copying" and "show warranty" for details. +This GDB was configured as "x86_64-redhat-linux-gnu". +Type "show configuration" for configuration details. +For bug reporting instructions, please see: +. +Find the GDB manual and other documentation resources online at: + . + +For help, type "help". +Type "apropos word" to search for commands related to "word"... +Reading symbols from /bi/apps/R/R-4.4.0/bin/exec/R... +(gdb) run +Starting program: /bi/apps/R/R-4.4.0/bin/exec/R --vanilla --no-echo -e tools:::makeLazyLoading\(\"grDevices\"\) +[Thread debugging using libthread_db enabled] +Using host libthread_db library "/lib64/libthread_db.so.1". +[Detaching after vfork from child process 2621570] +[Detaching after vfork from child process 2621572] + +Program received signal SIGSEGV, Segmentation fault. +dlaswp (n=, a=, lda=, k1=, k2=, ipiv=..., + incx=1) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dlaswp.f:180 +180 TEMP = A( I, K ) +Missing separate debuginfos, use: dnf debuginfo-install glibc-2.34-83.el9_3.7.x86_64 libgcc-11.4.1-2.1.el9.alma.x86_64 libgfortran-11.4.1-2.1.el9.alma.x86_64 libgomp-11.4.1-2.1.el9.alma.x86_64 libquadmath-11.4.1-2.1.el9.alma.x86_64 libstdc++-11.4.1-2.1.el9.alma.x86_64 pcre2-10.40-2.el9.x86_64 +(gdb) bt +#0 dlaswp (n=, a=, lda=, k1=, k2=, + ipiv=..., incx=1) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dlaswp.f:180 +#1 0x00007ffff3f9474a in dgetrf2 (m=12884901891, n=, a=, lda=12884901891, ipiv=..., + info=0) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:238 +#2 0x00007ffff3f946dc in dgetrf2 (m=12884901891, n=4, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:229 +#3 0x00007ffff3f946dc in dgetrf2 (m=12884901891, n=8, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:229 +#4 0x00007ffff3f946dc in dgetrf2 (m=12884901891, n=16, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:229 +#5 0x00007ffff3f946dc in dgetrf2 (m=12884901891, n=32, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:229 +#6 0x00007ffff3f946dc in dgetrf2 (m=12884901891, n=64, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf2.f:229 +#7 0x00007ffff3f94cb4 in dgetrf (m=12884901891, n=12884901891, a=, lda=12884901891, ipiv=..., info=0) + at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgetrf.f:183 +#8 0x00007ffff3f87c0b in dgesv (n=12884901891, nrhs=4294967299, a=, lda=12884901891, ipiv=..., + b=, ldb=12884901891, info=0) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 +#9 0x00007ffff50b2a17 in La_solve (tolin=, Bin=, A=0x18f2f68) at Lapack.c:1246 +#10 mod_do_lapack (call=, op=, args=, env=) at Lapack.c:1483 +#11 0x00007ffff7c95668 in bcEval_loop (ploc=) at eval.c:8141 +#12 0x00007ffff7cb0f4d in bcEval (rho=0x19027c8, body=0x18fc7a0) at eval.c:7524 +#13 bcEval (body=0x18fc7a0, rho=0x19027c8) at eval.c:7509 +#14 0x00007ffff7cb127b in Rf_eval (e=e at entry=0x18fc7a0, rho=rho at entry=0x19027c8) at eval.c:1167 +#15 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x1902918, newrho=newrho at entry=0x19027c8, sysparent=, rho=rho at entry=0x18f8508, + arglist=arglist at entry=0x18f85e8, op=op at entry=0x18fcae8) at eval.c:2398 +#16 0x00007ffff7cb40f7 in applyClosure_core (call=0x1902918, op=0x18fcae8, arglist=0x18f85e8, rho=0x18f8508, suppliedvars=, + unpromise=unpromise at entry=FALSE) at eval.c:2311 +#17 0x00007ffff7cb4b19 in Rf_applyClosure (call=, op=, arglist=, rho=, + suppliedvars=, unpromise=unpromise at entry=FALSE) at eval.c:2333 +#18 0x00007ffff7cf6cce in applyMethod (call=call at entry=0x1902918, op=op at entry=0x18fcae8, args=, rho=rho at entry=0x18f8508, + newvars=newvars at entry=0x1902988) at objects.c:120 +#19 0x00007ffff7cf7e44 in dispatchMethod (op=op at entry=0x18f8818, sxp=0x18fcae8, dotClass=, cptr=cptr at entry=0x7fffffff5bc0, + method=method at entry=0x524110, generic=generic at entry=0x4c9080 "solve", rho=, callrho=, defrho=) + at objects.c:472 +#20 0x00007ffff7cf8457 in Rf_usemethod (generic=0x4c9080 "solve", obj=obj at entry=0x18f2f68, call=call at entry=0x18f8700, args=args at entry=0x423210, + rho=rho at entry=0x18f8508, callrho=0x18f74c8, defrho=0x45a470, ans=0x7fffffff3ea8) at objects.c:522 +#21 0x00007ffff7cf882b in do_usemethod (call=0x18f8700, op=, args=, env=0x18f8508) at objects.c:578 +#22 0x00007ffff7c9548f in bcEval_loop (ploc=) at eval.c:7172 +#23 0x00007ffff7cb0f4d in bcEval (rho=0x18f8508, body=0x18f8738) at eval.c:7524 +#24 bcEval (body=0x18f8738, rho=0x18f8508) at eval.c:7509 +#25 0x00007ffff7cb127b in Rf_eval (e=e at entry=0x18f8738, rho=rho at entry=0x18f8508) at eval.c:1167 +#26 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x1625058, newrho=newrho at entry=0x18f8508, sysparent=, rho=rho at entry=0x18f74c8, + arglist=arglist at entry=0x18f85e8, op=op at entry=0x18f8818) at eval.c:2398 +#27 0x00007ffff7cb40f7 in applyClosure_core (call=call at entry=0x1625058, op=op at entry=0x18f8818, arglist=0x18f85e8, rho=rho at entry=0x18f74c8, + suppliedvars=, unpromise=unpromise at entry=TRUE) at eval.c:2311 +#28 0x00007ffff7cb13ac in Rf_applyClosure (unpromise=TRUE, suppliedvars=, rho=0x18f74c8, arglist=, op=0x18f8818, call=0x1625058) + at eval.c:2333 +#29 Rf_eval (e=0x1625058, rho=rho at entry=0x18f74c8) at eval.c:1285 +#30 0x00007ffff7cb649f in Rf_evalList (el=0x1625020, rho=rho at entry=0x18f74c8, call=call at entry=0x1624fb0, n=, n at entry=0) at eval.c:3680 +#31 0x00007ffff7cb17aa in Rf_eval (e=0x1624fb0, rho=0x18f74c8) at eval.c:1256 +#32 0x00007ffff7cb1c55 in forcePromise (e=0x18f8a48) at eval.c:976 +--Type for more, q to quit, c to continue without paging-- +#33 forcePromise (e=0x18f8a48) at eval.c:954 +#34 0x00007ffff7cb1ed0 in getvar (symbol=0x48b050, rho=0x18f89a0, dd=, keepmiss=FALSE, vcache=, sidx=) + at eval.c:5857 +#35 0x00007ffff7c9dc4e in bcEval_loop (ploc=) at eval.c:7871 +#36 0x00007ffff7cb0f4d in bcEval (rho=0x18f89a0, body=0x18f8bd0) at eval.c:7524 +#37 bcEval (body=0x18f8bd0, rho=0x18f89a0) at eval.c:7509 +#38 0x00007ffff7cb127b in Rf_eval (e=e at entry=0x18f8bd0, rho=rho at entry=0x18f89a0) at eval.c:1167 +#39 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x1624e98, newrho=newrho at entry=0x18f89a0, sysparent=, rho=rho at entry=0x18f74c8, + arglist=arglist at entry=0x18f8a10, op=op at entry=0x18f8c40) at eval.c:2398 +#40 0x00007ffff7cb40f7 in applyClosure_core (call=call at entry=0x1624e98, op=op at entry=0x18f8c40, arglist=0x18f8a10, rho=rho at entry=0x18f74c8, + suppliedvars=, unpromise=unpromise at entry=TRUE) at eval.c:2311 +#41 0x00007ffff7cb13ac in Rf_applyClosure (unpromise=TRUE, suppliedvars=, rho=0x18f74c8, arglist=, op=0x18f8c40, call=0x1624e98) + at eval.c:2333 +#42 Rf_eval (e=0x1624e98, rho=rho at entry=0x18f74c8) at eval.c:1285 +#43 0x00007ffff7cb6322 in do_set (call=0x1624df0, op=0x421338, args=0x1624e28, rho=0x18f74c8) at ../../src/include/Rinlinedfuns.h:90 +#44 0x00007ffff7cb16b6 in Rf_eval (e=0x1624df0, rho=rho at entry=0x18f74c8) at eval.c:1237 +#45 0x00007ffff7cb4e68 in do_begin (call=0x1621a78, op=0x42c4a0, args=0x1624db8, rho=0x18f74c8) at ../../src/include/Rinlinedfuns.h:90 +#46 0x00007ffff7cb16b6 in Rf_eval (e=e at entry=0x1621a78, rho=rho at entry=0x18f74c8) at eval.c:1237 +#47 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x1631a40, newrho=newrho at entry=0x18f74c8, sysparent=, rho=rho at entry=0x15a65c8, + arglist=arglist at entry=0x18f7880, op=op at entry=0x18d38d8) at eval.c:2398 +#48 0x00007ffff7cb40f7 in applyClosure_core (call=call at entry=0x1631a40, op=op at entry=0x18d38d8, arglist=0x18f7880, rho=rho at entry=0x15a65c8, + suppliedvars=, unpromise=unpromise at entry=TRUE) at eval.c:2311 +#49 0x00007ffff7cb13ac in Rf_applyClosure (unpromise=TRUE, suppliedvars=, rho=0x15a65c8, arglist=, op=0x18d38d8, call=0x1631a40) + at eval.c:2333 +#50 Rf_eval (e=0x1631a40, rho=rho at entry=0x15a65c8) at eval.c:1285 +#51 0x00007ffff7cb649f in Rf_evalList (el=0x1631928, rho=rho at entry=0x15a65c8, call=call at entry=0x16497a0, n=, n at entry=0) at eval.c:3680 +#52 0x00007ffff7cb17aa in Rf_eval (e=0x16497a0, rho=rho at entry=0x15a65c8) at eval.c:1256 +#53 0x00007ffff7cb6322 in do_set (call=0x16496f8, op=0x421338, args=0x1649730, rho=0x15a65c8) at ../../src/include/Rinlinedfuns.h:90 +#54 0x00007ffff7cb16b6 in Rf_eval (e=0x16496f8, rho=rho at entry=0x15a65c8) at eval.c:1237 +#55 0x00007ffff7cb7b46 in do_eval (call=, op=, args=, rho=0x18d5d70) at eval.c:3974 +#56 0x00007ffff7c95668 in bcEval_loop (ploc=) at eval.c:8141 +#57 0x00007ffff7cb0f4d in bcEval (rho=0x1517590, body=0x7e06a0) at eval.c:7524 +#58 bcEval (body=0x7e06a0, rho=0x1517590) at eval.c:7509 +#59 0x00007ffff7cb127b in Rf_eval (e=e at entry=0x7e06a0, rho=rho at entry=0x1517590) at eval.c:1167 +#60 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x78a960, newrho=newrho at entry=0x1517590, sysparent=, rho=rho at entry=0x8eb288, + arglist=arglist at entry=0x1517910, op=op at entry=0x7e0b70) at eval.c:2398 +#61 0x00007ffff7cb40f7 in applyClosure_core (call=call at entry=0x78a960, op=op at entry=0x7e0b70, arglist=0x1517910, rho=rho at entry=0x8eb288, + suppliedvars=, unpromise=unpromise at entry=TRUE) at eval.c:2311 +#62 0x00007ffff7cb13ac in Rf_applyClosure (unpromise=TRUE, suppliedvars=, rho=0x8eb288, arglist=, op=0x7e0b70, call=0x78a960) + at eval.c:2333 +#63 Rf_eval (e=0x78a960, rho=rho at entry=0x8eb288) at eval.c:1285 +#64 0x00007ffff7cb6322 in do_set (call=0x78a8b8, op=0x421338, args=0x78a8f0, rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90 +#65 0x00007ffff7cb16b6 in Rf_eval (e=0x78a8b8, rho=rho at entry=0x8eb288) at eval.c:1237 +#66 0x00007ffff7cb4e68 in do_begin (call=0x78a880, op=0x42c4a0, args=0x78a848, rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90 +#67 0x00007ffff7cb16b6 in Rf_eval (e=e at entry=0x78a880, rho=rho at entry=0x8eb288) at eval.c:1237 +#68 0x00007ffff7cb92ac in do_for (call=, op=, args=, rho=) at eval.c:2892 +#69 0x00007ffff7cb16b6 in Rf_eval (e=0x78a068, rho=rho at entry=0x8eb288) at eval.c:1237 +#70 0x00007ffff7cb4e68 in do_begin (call=0x78a030, op=0x42c4a0, args=0x789ff8, rho=0x8eb288) at ../../src/include/Rinlinedfuns.h:90 +#71 0x00007ffff7cb16b6 in Rf_eval (e=e at entry=0x78a030, rho=rho at entry=0x8eb288) at eval.c:1237 +#72 0x00007ffff7cb330f in R_execClosure (call=call at entry=0x8eb330, newrho=newrho at entry=0x8eb288, sysparent=, rho=rho at entry=0x45a518, + arglist=arglist at entry=0x423210, op=op at entry=0x789e38) at eval.c:2398 +#73 0x00007ffff7cb40f7 in applyClosure_core (call=call at entry=0x8eb330, op=op at entry=0x789e38, arglist=0x423210, rho=rho at entry=0x45a518, +--Type for more, q to quit, c to continue without paging-- + suppliedvars=, unpromise=unpromise at entry=TRUE) at eval.c:2311 +#74 0x00007ffff7cb13ac in Rf_applyClosure (unpromise=TRUE, suppliedvars=, rho=0x45a518, arglist=, op=0x789e38, call=0x8eb330) + at eval.c:2333 +#75 Rf_eval (e=0x8eb330, rho=0x45a518) at eval.c:1285 +#76 0x00007ffff7ce5a57 in setup_Rmainloop () at main.c:1166 +#77 0x00007ffff7ce6ae9 in Rf_mainloop () at main.c:1222 +#78 0x000000000040106b in main (ac=, av=) at Rmain.c:29 + + + +-----Original Message----- +From: Ivan Krylov +Sent: 08 May 2024 15:12 +To: Simon Andrews via R-help +Cc: Simon Andrews ; Miguel Esteva +Subject: Re: [R] Compilation problems with R4.4.0 + +Dear Simon, + +? Wed, 8 May 2024 10:17:41 +0000 +Simon Andrews via R-help ?????: + +> I'm having a strange problem compiling R4.4.0 on an AlmaLinux9 box. + +> make[4]: Entering directory '/bi/apps/R/R-4.4.0/src/library/grDevices' +> byte-compiling package 'grDevices' +> +> *** caught segfault *** +> address 0x18017a8110, cause 'memory not mapped' +> +> Traceback: +> 1: solve.default(rgb) + +Miguel Esteva has recently complained about the same problem on RHEL9, but didn't provide enough details, nor was I able to reproduce it +myself: https://stat.ethz.ch/pipermail/r-help/2024-May/479288.html + +Thanks for letting us know it's reproducible on AlmaLinux and telling us your compiler version! + +Unfortunately, I wasn't able to reproduce the crash, neither with gcc-toolset-13, nor with the ordinary gcc & gfortran 11.4.1 20231218 (Red Hat 11.4.1-3) from the repository. I see that your compiler version is slightly different (11.4.1-2). I'm running `podman run -it --rm almalinux:9`. Would an upgrade help? + +Can you run R under the debugger and obtain a backtrace? Something like the following, in the src/library/grDevices subdirectory: + +_R_COMPILE_PKGS_=1 R_COMPILER_SUPPRESS_ALL=1 \ R_DEFAULT_PACKAGES=NULL LC_ALL=C \ ../../../bin/R -d gdb --vanilla --no-echo -e \ 'tools:::makeLazyLoading("grDevices")' + +-- +Best regards, +Ivan + +------------------------------------ +This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxNzc1NTg7dXVpZD02NjNCODg1NTEyNjcyMzlDMjY5RkMwQTY5MUE2RDg5Njt0b2tlbj0zZjFiOWNmMGM5NTY3NjU3YjM0YmZhY2QwMTEzM2E3YmRlMDUxY2IwOw%3D%3D). + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 17:09:12 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 18:09:12 +0300 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: +References: + <20240508171228.0b2d930e@arachnoid> + +Message-ID: <20240508180912.109a9868@arachnoid> + +? Wed, 8 May 2024 14:25:08 +0000 +Simon Andrews ?????: + +> #8 0x00007ffff3f87c0b in dgesv ( +> n=12884901891, nrhs=4294967299, +> a=, +> lda=12884901891, ipiv=..., +> b=, +> ldb=12884901891, info=0 +> ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 +> #9 0x00007ffff50b2a17 in La_solve ( +> tolin=, Bin=, A=0x18f2f68 +> ) at Lapack.c:1246 +> #10 mod_do_lapack ( +> call=, op=, args=, +> env= +> ) at Lapack.c:1483 + +It looks like this R build is linked to a LAPACK. I now also notice +LAPACK(generic) in the list of external libraries in your ./configure +output. I've tried to link R to AlmaLinux's builds of reference BLAS +and LAPACK using --with-blas='-l:libblas.so.3' +--with-lapack='-l:liblapack.so.3' (where do I get libblas.so on +AlmaLinux?), but that doesn't crash either. + +What does the config.log currently say about your BLAS and LAPACK +situation? It's a number of lines between + +configure:47012: checking whether 'struct tm' includes tm_gmtoff + +and + +configure:48858: checking for iconv.h. + +If you'd like to link your R to custom BLAS and LAPACK, try specifying +the necessary linker flags explicitly with --with-blas=-lwhatever, +--with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK +that come with R, try ./configure --without-blas --without-lapack. +Normally, R's ./configure tries to prevent linking to an external +LAPACK without linking to an external BLAS; I'm not sure how it got you +LAPACK(generic) without BLAS(generic). + +-- +Best regards, +Ivan + + +From @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk Wed May 8 18:59:25 2024 +From: @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk (Simon Andrews) +Date: Wed, 8 May 2024 16:59:25 +0000 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: <20240508180912.109a9868@arachnoid> +References: + <20240508171228.0b2d930e@arachnoid> + + <20240508180912.109a9868@arachnoid> +Message-ID: + +The lapack parts of the configure are: + +checking whether 'struct tm' includes tm_zone... yes +checking whether 'struct tm' includes tm_gmtoff... yes +checking for dgemm_ in -llapack... no +checking for ATLAS routines in liblapack... no +checking for dpstrf_ in -llapack... yes +checking for liblapack dependency with both BLAS and LAPACK routines... no +checking if LAPACK version >= 3.9.0... 3.9.0, so yes +checking for iconv.h... yes +checking for iconv... yes + +The lapack libraries are: + +$ rpm -qa | grep lapack +lapack-3.9.0-10.el9.x86_64 +lapack64_-3.9.0-10.el9.x86_64 +lapack64-3.9.0-10.el9.x86_64 +lapack-devel-3.9.0-10.el9.x86_64 + +-----Original Message----- +From: Ivan Krylov +Sent: 08 May 2024 16:09 +To: Simon Andrews +Cc: Simon Andrews via R-help ; Miguel Esteva +Subject: Re: [R] Compilation problems with R4.4.0 + +? Wed, 8 May 2024 14:25:08 +0000 +Simon Andrews ?????: + +> #8 0x00007ffff3f87c0b in dgesv ( +> n=12884901891, nrhs=4294967299, +> a=, +> lda=12884901891, ipiv=..., b= optimized out>, ldb=12884901891, info=0 +> ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 +> #9 0x00007ffff50b2a17 in La_solve ( +> tolin=, Bin=, A=0x18f2f68 +> ) at Lapack.c:1246 +> #10 mod_do_lapack ( +> call=, op=, args=, +> env= +> ) at Lapack.c:1483 + +It looks like this R build is linked to a LAPACK. I now also notice +LAPACK(generic) in the list of external libraries in your ./configure output. I've tried to link R to AlmaLinux's builds of reference BLAS and LAPACK using --with-blas='-l:libblas.so.3' +--with-lapack='-l:liblapack.so.3' (where do I get libblas.so on AlmaLinux?), but that doesn't crash either. + +What does the config.log currently say about your BLAS and LAPACK situation? It's a number of lines between + +configure:47012: checking whether 'struct tm' includes tm_gmtoff + +and + +configure:48858: checking for iconv.h. + +If you'd like to link your R to custom BLAS and LAPACK, try specifying the necessary linker flags explicitly with --with-blas=-lwhatever, --with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK that come with R, try ./configure --without-blas --without-lapack. +Normally, R's ./configure tries to prevent linking to an external LAPACK without linking to an external BLAS; I'm not sure how it got you +LAPACK(generic) without BLAS(generic). + +-- +Best regards, +Ivan + +------------------------------------ +This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxODA5NjA7dXVpZD02NjNCOTVBMDY0RkEzNzNCMDM5QTkwQkZCQzJDRUJERjt0b2tlbj0yOTE5M2Q0NjFkZjQzYzhlMzk0ZDgxMTRkNjgyYTUwZjU3OWZlODgxOw%3D%3D). + + +From @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk Wed May 8 19:02:24 2024 +From: @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk (Simon Andrews) +Date: Wed, 8 May 2024 17:02:24 +0000 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: <20240508180912.109a9868@arachnoid> +References: + <20240508171228.0b2d930e@arachnoid> + + <20240508180912.109a9868@arachnoid> +Message-ID: + +Also just did a full errata update and retried the compilation. It failed exactly as before. + +-----Original Message----- +From: Ivan Krylov +Sent: 08 May 2024 16:09 +To: Simon Andrews +Cc: Simon Andrews via R-help ; Miguel Esteva +Subject: Re: [R] Compilation problems with R4.4.0 + +? Wed, 8 May 2024 14:25:08 +0000 +Simon Andrews ?????: + +> #8 0x00007ffff3f87c0b in dgesv ( +> n=12884901891, nrhs=4294967299, +> a=, +> lda=12884901891, ipiv=..., b= optimized out>, ldb=12884901891, info=0 +> ) at /usr/src/debug/lapack-3.9.0-10.el9.x86_64/SRC/dgesv.f:167 +> #9 0x00007ffff50b2a17 in La_solve ( +> tolin=, Bin=, A=0x18f2f68 +> ) at Lapack.c:1246 +> #10 mod_do_lapack ( +> call=, op=, args=, +> env= +> ) at Lapack.c:1483 + +It looks like this R build is linked to a LAPACK. I now also notice +LAPACK(generic) in the list of external libraries in your ./configure output. I've tried to link R to AlmaLinux's builds of reference BLAS and LAPACK using --with-blas='-l:libblas.so.3' +--with-lapack='-l:liblapack.so.3' (where do I get libblas.so on AlmaLinux?), but that doesn't crash either. + +What does the config.log currently say about your BLAS and LAPACK situation? It's a number of lines between + +configure:47012: checking whether 'struct tm' includes tm_gmtoff + +and + +configure:48858: checking for iconv.h. + +If you'd like to link your R to custom BLAS and LAPACK, try specifying the necessary linker flags explicitly with --with-blas=-lwhatever, --with-lapack=-lwhatever. If you're fine with reference BLAS & LAPACK that come with R, try ./configure --without-blas --without-lapack. +Normally, R's ./configure tries to prevent linking to an external LAPACK without linking to an external BLAS; I'm not sure how it got you +LAPACK(generic) without BLAS(generic). + +-- +Best regards, +Ivan + +------------------------------------ +This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxODA5NjA7dXVpZD02NjNCOTVBMDY0RkEzNzNCMDM5QTkwQkZCQzJDRUJERjt0b2tlbj0yOTE5M2Q0NjFkZjQzYzhlMzk0ZDgxMTRkNjgyYTUwZjU3OWZlODgxOw%3D%3D). + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 21:05:15 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 22:05:15 +0300 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: +References: + <20240508171228.0b2d930e@arachnoid> + + <20240508180912.109a9868@arachnoid> + +Message-ID: <20240508220515.77946bc0@Tarkus> + +? Wed, 8 May 2024 16:59:25 +0000 +Simon Andrews ?????: + +> The lapack libraries are: +> +> $ rpm -qa | grep lapack +> lapack-3.9.0-10.el9.x86_64 +> lapack64_-3.9.0-10.el9.x86_64 +> lapack64-3.9.0-10.el9.x86_64 +> lapack-devel-3.9.0-10.el9.x86_64 + +Thanks for this information! I figured out I needed to enable the +"PowerTools/CRB" repo, installed lapack-devel from there, and now I get +the same configure output and the same crash: by linking with R's +built-in Rblas but and system-provided LAPACK-3.9.0. + +If I configure --without-lapack, i.e. use both Rblas and R-provided +functions from LAPACK up to 3.12.0, the build doesn't crash. + +If I try to enable --with-blas=-lblas, here's what happens: + +configure:47862: checking whether double complex BLAS can be used +configure:47946: result: no + +The test compares the result of the BLAS function zdotu with the +manually computed vector norm for a complex vector [*]. In this case, +the Fortran program thinks that the BLAS returns a zero instead of the +correct answer, thus failing the test and refusing to compile with +system BLAS. + +I think that you somehow stumbled upon a Fortran ABI incompatibility +regarding passing complex numbers between the Fortran code compiled +during R build and the BLAS and LAPACK provided in the PowerTools/CRB +repo. I don't know what exactly is the problem, but at least +--without-lapack is an easy workaround without any cost in performance. + +In fact, if you install openblas-devel and configure --with-blas (to +replace Rblas with OpenBLAS), the double complex BLAS test will pass, +the build won't crash, and you will get even better performance. + +-- +Best regards, +Ivan + +[*] https://stat.ethz.ch/pipermail/r-devel/2024-March/083302.html + + +From tb|e|@kov@ @end|ng |rom @tudent@ethz@ch Wed May 8 12:36:32 2024 +From: tb|e|@kov@ @end|ng |rom @tudent@ethz@ch (Bielakova Tatiana) +Date: Wed, 8 May 2024 10:36:32 +0000 +Subject: [R] + Using intervals() function for nlme model - Statistics Lab ETHZ +In-Reply-To: <20240506172425.7a569ed1@arachnoid> +References: <9a74d1234c254b40b9a7d5cd119ba08a@student.ethz.ch>, + <20240506172425.7a569ed1@arachnoid> +Message-ID: <700cb1b560534796a7027b7f60623859@student.ethz.ch> + +Dear Ivan, + +thanks for the insights! This points us directly in the direction we need. + +Have a lovely day! + +Yours sincerely, +Tatiana, Marvin & Paul +from +Statistics Lab + + + +________________________________ +From: Ivan Krylov +Sent: Monday, May 6, 2024 4:24 PM +To: Bielakova Tatiana +Cc: R-help at r-project.org; Stephan Paul Andreas Kurt; Lob Marvin +Subject: Re: [R] Using intervals() function for nlme model - Statistics Lab ETHZ + +Dear Tatiana, Marvin & Paul, + +If you don't get a better answer here, try +r-sig-mixed-models at r-project.org. + +On Fri, 3 May 2024 11:29:19 +0000 +"Bielakova Tatiana" wrote: + +> Based on the documentation of nlme package, the function interval is +> supported for gls, lme, and lmList classes. Although nlme is not +> mentioned, we still receive intervals without any errors or warnings. + +You're right to question this. Programming-language-level inheritance +ends up being backwards for statistical methods: +. +Linear mixed-effect models are a subset of the more general mixed-effect +models, but in R, "nlme" objects inherit from "lme", not the other way +around. + +> * Do you have any other recommendations/ ideas on how should we +> proceed to calculate intervals in R (e.g. more suitable packages)? + +Here's a vignette from the nlraa package where bootstrap is used to get +a confidence interval for an implicit parameter: +https://cran.r-project.org/package=nlraa/vignettes/Bootstrapping.html + +The author seems to be using intervals() on an nlme model without any +problems. It may help to see if the intervals() output agrees with the +bootstrap results from nlraa::boot_nlme(). + +-- +Best regards, +Ivan + + [[alternative HTML version deleted]] + + +From gdu|ey @end|ng |rom gm@||@com Wed May 8 22:57:56 2024 +From: gdu|ey @end|ng |rom gm@||@com (Gavin Duley) +Date: Wed, 8 May 2024 22:57:56 +0200 +Subject: [R] Problem with creating a PCA graph in a loop +In-Reply-To: <20240508101638.630564b1@Tarkus> +References: + <20240508101638.630564b1@Tarkus> +Message-ID: <934E8595-60B8-42AA-B2A6-7F446A4747CE@gmail.com> + +> On 8 May 2024, at 09:16, Ivan Krylov wrote: +> +> ? Tue, 7 May 2024 16:57:14 +0200 +> gavin duley ?????: +> +>> aes(label=current_rownames, +>> colour=wine.data.filt$Treatment +>> ) +> +> As you've noticed, aes() remembers variables by their name and +> environment, not by value: + +Yes, it was something I wasn?t aware of previously. I thought once I?d created a ggplot object, it was fairly static/unchanging. + +That this is limited to aes() explains why the title set using ggtitle isn?t affected in the same way ? thanks! + +> One way to get around the problem is to ensure that the variables live +> in different environments. Instead of making it a for loop, write a +> function that would accept `i` and return a plot instead of assigning +> it by name: + +Thanks, that does seem like a good option. I?m less familiar with writing functions, but it?s something I?m trying to learn about. I?ll try it and see how it goes. + +> (In many languages, trying to use a variable as a variable name, while +> possible, usually means you need to consider some kind of nested data +> structure: +> https://perldoc.perl.org/perlfaq7#How-can-I-use-a-variable-as-a-variable-name? +> In R, this structure is a list.) + +Ok, that?s useful to know, thanks. I don?t really have much programming experience beyond R, so there?s a lot I don?t know. + +> Alternatively, supply a data= argument to geom_label_repel() and make +> your mapping = aes(...) reference variables from the data (which will +> be remembered), ignoring the environment (which is only referenced). +> Something like the following should work, untested: + + +Thanks, I?ll try that out too. + +Many thanks for giving me a few suggestions. I was completely stuck, but these have given me a few good things to try! + +Thanks, +gavin, + +From |kry|ov @end|ng |rom d|@root@org Thu May 9 11:27:24 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 9 May 2024 12:27:24 +0300 +Subject: [R] + Using intervals() function for nlme model - Statistics Lab ETHZ +In-Reply-To: <700cb1b560534796a7027b7f60623859@student.ethz.ch> +References: <9a74d1234c254b40b9a7d5cd119ba08a@student.ethz.ch> + <20240506172425.7a569ed1@arachnoid> + <700cb1b560534796a7027b7f60623859@student.ethz.ch> +Message-ID: <20240509122724.7d0eefd9@trisector> + +Just one more thing: when you do find a solution, can you please share +it with us? + +I do trust nlraa::boot_nlme() as it's been deliberately written for +nonlinear mixed-effects models, but the fact that intervals() is +inherited from the 'lme' class without any mention of nonlinear models +in the manual worries me. I don't know if it's intended to work with +'nlme' models. + +-- +Best regards, +Ivan + + +From n@re@h_gurbux@n| @end|ng |rom hotm@||@com Thu May 9 14:09:03 2024 +From: n@re@h_gurbux@n| @end|ng |rom hotm@||@com (Naresh Gurbuxani) +Date: Thu, 9 May 2024 08:09:03 -0400 +Subject: [R] Strange variable names in factor regression +Message-ID: + + +On converting character variables to ordered factors, regression result +has strange names. Is it possible to obtain same variable names with +and without intercept? + +Thanks, +Naresh + +mydf <- data.frame(date = seq.Date(as.Date("2024-01-01"), +as.Date("2024-03-31"), by = 1)) +mydf[, "wday"] <- weekdays(mydf$date, abbreviate = TRUE) +mydf.work <- subset(mydf, !(wday %in% c("Sat", "Sun"))) +mydf.weekend <- subset(mydf, wday %in% c("Sat", "Sun")) +mydf.work[, "volume"] <- round(rnorm(nrow(mydf.work), mean = 20, sd = +5)) +mydf.weekend[, "volume"] <- round(rnorm(nrow(mydf.weekend), mean = 10, +sd = 5)) +mydf <- rbind(mydf.work, mydf.weekend) + +reg <- lm(volume ~ wday, data = mydf) +## Variable names as expected +coef(reg) +(Intercept) wdayMon wdaySat wdaySun wdayThu wdayTue +21.3846154 1.3076923 -12.0000000 -12.9230769 -1.9230769 -0.6923077 +wdayWed +-1.6153846 + +reg <- lm(volume ~ wday - 1, data = mydf) +# Variable names as expected +coef(reg) +wdayFri wdayMon wdaySat wdaySun wdayThu wdayTue wdayWed +21.384615 22.692308 9.384615 8.461538 19.461538 20.692308 19.769231 + +# Ordered factors for weekday sequence +mydf$wday <- factor(mydf$wday, levels = c("Mon", "Tue", "Wed", "Thu", +"Fri", "Sat", "Sun"), ordered = TRUE) + +reg <- lm(volume ~ wday - 1, data = mydf) +# Variable names as expected +coef(reg) +wdayMon wdayTue wdayWed wdayThu wdayFri wdaySat wdaySun +22.692308 20.692308 19.769231 19.461538 21.384615 9.384615 8.461538 + +reg <- lm(volume ~ wday, data = mydf) +# Strange variable names +coef(reg) +(Intercept) wday.L wday.Q wday.C wday^4 wday^5 +17.406593 -12.036715 -4.968654 -1.852819 3.291477 4.263642 +wday^6 +2.591317 + + +From @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk Thu May 9 14:19:49 2024 +From: @|mon@@ndrew@ @end|ng |rom b@br@h@m@@c@uk (Simon Andrews) +Date: Thu, 9 May 2024 12:19:49 +0000 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: <20240508220515.77946bc0@Tarkus> +References: + <20240508171228.0b2d930e@arachnoid> + + <20240508180912.109a9868@arachnoid> + + <20240508220515.77946bc0@Tarkus> +Message-ID: + +Thank you! + +Installing openblas and then using ./configure --without-lapack --with-blas --enable-R-shlib + +..got everything working. Does this need reporting upstream as a bug in R or lapack? I'm good now, but it might help others to get this fixed. + +Simon. + +-----Original Message----- +From: Ivan Krylov +Sent: 08 May 2024 20:05 +To: Simon Andrews +Cc: Simon Andrews via R-help ; Miguel Esteva +Subject: Re: [R] Compilation problems with R4.4.0 + +? Wed, 8 May 2024 16:59:25 +0000 +Simon Andrews ?????: + +> The lapack libraries are: +> +> $ rpm -qa | grep lapack +> lapack-3.9.0-10.el9.x86_64 +> lapack64_-3.9.0-10.el9.x86_64 +> lapack64-3.9.0-10.el9.x86_64 +> lapack-devel-3.9.0-10.el9.x86_64 + +Thanks for this information! I figured out I needed to enable the "PowerTools/CRB" repo, installed lapack-devel from there, and now I get the same configure output and the same crash: by linking with R's built-in Rblas but and system-provided LAPACK-3.9.0. + +If I configure --without-lapack, i.e. use both Rblas and R-provided functions from LAPACK up to 3.12.0, the build doesn't crash. + +If I try to enable --with-blas=-lblas, here's what happens: + +configure:47862: checking whether double complex BLAS can be used +configure:47946: result: no + +The test compares the result of the BLAS function zdotu with the manually computed vector norm for a complex vector [*]. In this case, the Fortran program thinks that the BLAS returns a zero instead of the correct answer, thus failing the test and refusing to compile with system BLAS. + +I think that you somehow stumbled upon a Fortran ABI incompatibility regarding passing complex numbers between the Fortran code compiled during R build and the BLAS and LAPACK provided in the PowerTools/CRB repo. I don't know what exactly is the problem, but at least --without-lapack is an easy workaround without any cost in performance. + +In fact, if you install openblas-devel and configure --with-blas (to replace Rblas with OpenBLAS), the double complex BLAS test will pass, the build won't crash, and you will get even better performance. + +-- +Best regards, +Ivan + +[*] https://stat.ethz.ch/pipermail/r-devel/2024-March/083302.html + +------------------------------------ +This email has been scanned for spam & viruses. If you believe this email should have been stopped by our filters, click the following link to report it (https://portal-uk.mailanyone.net/index.html#/outer/reportspam?token=dXNlcj1zaW1vbi5hbmRyZXdzQGJhYnJhaGFtLmFjLnVrO3RzPTE3MTUxOTUxMjQ7dXVpZD02NjNCQ0NGMzA1RDJGMzA3RDhDMjIxQTZCRUE3MEQ3MDt0b2tlbj0yZTdkOWY0ZjNjZmQ2NGQyZGFlMmYwZjQ2MTk5NjdmODk2ZDM3YjQyOw%3D%3D). + + +From murdoch@dunc@n @end|ng |rom gm@||@com Thu May 9 14:49:39 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Thu, 9 May 2024 08:49:39 -0400 +Subject: [R] Strange variable names in factor regression +In-Reply-To: +References: +Message-ID: <575b2e56-ee7e-46f6-8ef7-4ceeb5e566c4@gmail.com> + +On 09/05/2024 8:09 a.m., Naresh Gurbuxani wrote: +> +> On converting character variables to ordered factors, regression result +> has strange names. Is it possible to obtain same variable names with +> and without intercept? + +You are getting polynomial contrasts with the ordered factor, because +you have the default setting for options("contrasts"), i.e. + + unordered ordered +"contr.treatment" "contr.poly" + +If you run + + options(contrasts = c("contr.treatment", "contr.treatment")) + +you will get the same coefficient names in both cases. + +By the way, the coefficients have different meanings, so it makes sense +they will have different names. It's perhaps a little bit more of a +problem that you *don't* get different variable names when an intercept +is included or not, because those coefficients also have different meanings. + +It may also be a little bit of a surprise that you go back to treatment +contrasts when you leave out the intercept with the ordered factor, but +then it almost never makes sense to leave out the intercept in a +polynomial fit. + +Duncan Murdoch + + +> +> Thanks, +> Naresh +> +> mydf <- data.frame(date = seq.Date(as.Date("2024-01-01"), +> as.Date("2024-03-31"), by = 1)) +> mydf[, "wday"] <- weekdays(mydf$date, abbreviate = TRUE) +> mydf.work <- subset(mydf, !(wday %in% c("Sat", "Sun"))) +> mydf.weekend <- subset(mydf, wday %in% c("Sat", "Sun")) +> mydf.work[, "volume"] <- round(rnorm(nrow(mydf.work), mean = 20, sd = +> 5)) +> mydf.weekend[, "volume"] <- round(rnorm(nrow(mydf.weekend), mean = 10, +> sd = 5)) +> mydf <- rbind(mydf.work, mydf.weekend) +> +> reg <- lm(volume ~ wday, data = mydf) +> ## Variable names as expected +> coef(reg) +> (Intercept) wdayMon wdaySat wdaySun wdayThu wdayTue +> 21.3846154 1.3076923 -12.0000000 -12.9230769 -1.9230769 -0.6923077 +> wdayWed +> -1.6153846 +> +> reg <- lm(volume ~ wday - 1, data = mydf) +> # Variable names as expected +> coef(reg) +> wdayFri wdayMon wdaySat wdaySun wdayThu wdayTue wdayWed +> 21.384615 22.692308 9.384615 8.461538 19.461538 20.692308 19.769231 +> +> # Ordered factors for weekday sequence +> mydf$wday <- factor(mydf$wday, levels = c("Mon", "Tue", "Wed", "Thu", +> "Fri", "Sat", "Sun"), ordered = TRUE) +> +> reg <- lm(volume ~ wday - 1, data = mydf) +> # Variable names as expected +> coef(reg) +> wdayMon wdayTue wdayWed wdayThu wdayFri wdaySat wdaySun +> 22.692308 20.692308 19.769231 19.461538 21.384615 9.384615 8.461538 +> +> reg <- lm(volume ~ wday, data = mydf) +> # Strange variable names +> coef(reg) +> (Intercept) wday.L wday.Q wday.C wday^4 wday^5 +> 17.406593 -12.036715 -4.968654 -1.852819 3.291477 4.263642 +> wday^6 +> 2.591317 +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + +From ||@t@ @end|ng |rom dewey@myzen@co@uk Thu May 9 14:49:43 2024 +From: ||@t@ @end|ng |rom dewey@myzen@co@uk (Michael Dewey) +Date: Thu, 9 May 2024 13:49:43 +0100 +Subject: [R] Strange variable names in factor regression +In-Reply-To: +References: +Message-ID: <0527f881-b75c-64aa-9965-6488c532936a@dewey.myzen.co.uk> + +Comment in in-line below + +On 09/05/2024 13:09, Naresh Gurbuxani wrote: +> +> On converting character variables to ordered factors, regression result +> has strange names. Is it possible to obtain same variable names with +> and without intercept? +> +> Thanks, +> Naresh +> +> mydf <- data.frame(date = seq.Date(as.Date("2024-01-01"), +> as.Date("2024-03-31"), by = 1)) +> mydf[, "wday"] <- weekdays(mydf$date, abbreviate = TRUE) +> mydf.work <- subset(mydf, !(wday %in% c("Sat", "Sun"))) +> mydf.weekend <- subset(mydf, wday %in% c("Sat", "Sun")) +> mydf.work[, "volume"] <- round(rnorm(nrow(mydf.work), mean = 20, sd = +> 5)) +> mydf.weekend[, "volume"] <- round(rnorm(nrow(mydf.weekend), mean = 10, +> sd = 5)) +> mydf <- rbind(mydf.work, mydf.weekend) +> +> reg <- lm(volume ~ wday, data = mydf) +> ## Variable names as expected +> coef(reg) +> (Intercept) wdayMon wdaySat wdaySun wdayThu wdayTue +> 21.3846154 1.3076923 -12.0000000 -12.9230769 -1.9230769 -0.6923077 +> wdayWed +> -1.6153846 +> +> reg <- lm(volume ~ wday - 1, data = mydf) +> # Variable names as expected +> coef(reg) +> wdayFri wdayMon wdaySat wdaySun wdayThu wdayTue wdayWed +> 21.384615 22.692308 9.384615 8.461538 19.461538 20.692308 19.769231 +> +> # Ordered factors for weekday sequence +> mydf$wday <- factor(mydf$wday, levels = c("Mon", "Tue", "Wed", "Thu", +> "Fri", "Sat", "Sun"), ordered = TRUE) +> +> reg <- lm(volume ~ wday - 1, data = mydf) +> # Variable names as expected +> coef(reg) +> wdayMon wdayTue wdayWed wdayThu wdayFri wdaySat wdaySun +> 22.692308 20.692308 19.769231 19.461538 21.384615 9.384615 8.461538 +> +> reg <- lm(volume ~ wday, data = mydf) +> # Strange variable names +> coef(reg) +> (Intercept) wday.L wday.Q wday.C wday^4 wday^5 +> 17.406593 -12.036715 -4.968654 -1.852819 3.291477 4.263642 +> wday^6 +> 2.591317 + + +Yes, that is what ordered is supposed to do, fit polynomial contrasts. +When you remove the intercept that breaks it so you get a different fit, +in fact the same as you got when it was not ordered. + +Michael + +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide +> http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. +> + +-- +Michael + + +From |kry|ov @end|ng |rom d|@root@org Thu May 9 16:52:10 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 9 May 2024 17:52:10 +0300 +Subject: [R] Compilation problems with R4.4.0 +In-Reply-To: +References: + <20240508171228.0b2d930e@arachnoid> + + <20240508180912.109a9868@arachnoid> + + <20240508220515.77946bc0@Tarkus> + +Message-ID: <20240509175210.366b4efc@Tarkus> + +Glad you got R working! + +? Thu, 9 May 2024 12:19:49 +0000 +Simon Andrews ?????: + +> Does this need reporting upstream as a bug in R or lapack? + +Maybe in AlmaLinux (and I think RHEL9 too, but that's up to Miguel +Esteva). Best case scenario, they somehow built the reference BLAS and +LAPACK packages with the wrong Fortran compiler version or flags, which +is why gfortran-11 gets a zero instead of the return value from DOUBLE +COMPLEX zdotu(...) and crashes when calling dgesv(...) from +lapack-3.9.0-10.el9.x86_64. Worst case scenario, the zdotu() problem +and the crash have two completely different causes elsewhere. + +-- +Best regards, +Ivan + + +From j@ork|n @end|ng |rom @om@um@ry|@nd@edu Fri May 10 01:58:32 2024 +From: j@ork|n @end|ng |rom @om@um@ry|@nd@edu (Sorkin, John) +Date: Thu, 9 May 2024 23:58:32 +0000 +Subject: [R] Print date on y axis with month, day, and year +Message-ID: + +I am trying to use ggplot to plot the data, and R code, below. The dates (jdate) are printing as Mar 01, Mar 15, etc. I want to have the date printed as MMM DD YYYY (or any other way that will show month, date, and year, e.g. mm/dd/yy). How can I accomplish this? + +yyy <- structure(list( + jdate = structure(c(19052, 19053, 19054, 19055, + 19058, 19059, 19060, 19061, 19062, 19063, 19065, 19066, 19067, + 19068, 19069, 19072, 19073, 19074, 19075, 19076, 19077, 19083, + 19086, 19087, 19088, 19089, 19090, 19093, 19094, 19095), class = "Date"), + Sum = c ( 1, 3, 9, 11, 13, 16, 18, 22, 26, 27, 30, 32, 35, 39, 41, + 43, 48, 51, 56, 58, 59, 63, 73, 79, 81, 88, 91, 93, 96, 103)), + row.names = c(NA, 30L), class = "data.frame") +yyy +class(yyy$jdate) +ggplot(data=yyy[1:30,],aes(as.Date(jdate,format="%m-%d-%Y"),Sum)) +geom_point() + + +Thank you +John + + + +John David Sorkin M.D., Ph.D. +Professor of Medicine, University of Maryland School of Medicine; +Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center;? +PI?Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; +Senior Statistician University of Maryland Center for Vascular Research; + +Division of Gerontology and Paliative Care, +10 North Greene Street +GRECC (BT/18/GR) +Baltimore, MD 21201-1524 +Cell phone 443-418-5382 + + + + +From bbo|ker @end|ng |rom gm@||@com Fri May 10 02:13:36 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 9 May 2024 20:13:36 -0400 +Subject: [R] Print date on y axis with month, day, and year +In-Reply-To: +References: +Message-ID: <0be8f9f1-c7c6-4f67-b7b8-38546bbefa6f@gmail.com> + +gg0 <- ggplot(data=yyy[1:30,],aes(as.Date(jdate,format="%m-%d-%Y"),Sum)) ++geom_point() +gg0 + scale_x_date(date_labels = "%m/%d/%Y") + + +On 2024-05-09 7:58 p.m., Sorkin, John wrote: +> I am trying to use ggplot to plot the data, and R code, below. The dates (jdate) are printing as Mar 01, Mar 15, etc. I want to have the date printed as MMM DD YYYY (or any other way that will show month, date, and year, e.g. mm/dd/yy). How can I accomplish this? +> +> yyy <- structure(list( +> jdate = structure(c(19052, 19053, 19054, 19055, +> 19058, 19059, 19060, 19061, 19062, 19063, 19065, 19066, 19067, +> 19068, 19069, 19072, 19073, 19074, 19075, 19076, 19077, 19083, +> 19086, 19087, 19088, 19089, 19090, 19093, 19094, 19095), class = "Date"), +> Sum = c ( 1, 3, 9, 11, 13, 16, 18, 22, 26, 27, 30, 32, 35, 39, 41, +> 43, 48, 51, 56, 58, 59, 63, 73, 79, 81, 88, 91, 93, 96, 103)), +> row.names = c(NA, 30L), class = "data.frame") +> yyy +> class(yyy$jdate) +> ggplot(data=yyy[1:30,],aes(as.Date(jdate,format="%m-%d-%Y"),Sum)) +geom_point() +> +> +> Thank you +> John +> +> +> +> John David Sorkin M.D., Ph.D. +> Professor of Medicine, University of Maryland School of Medicine; +> Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center; +> PI?Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; +> Senior Statistician University of Maryland Center for Vascular Research; +> +> Division of Gerontology and Paliative Care, +> 10 North Greene Street +> GRECC (BT/18/GR) +> Baltimore, MD 21201-1524 +> Cell phone 443-418-5382 +> +> +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + +From Ro@@@Boy|@n @end|ng |rom uc@|@edu Fri May 10 05:46:54 2024 +From: Ro@@@Boy|@n @end|ng |rom uc@|@edu (Boylan, Ross) +Date: Fri, 10 May 2024 03:46:54 +0000 +Subject: [R] R CMD check vs RStudio check +In-Reply-To: <20240503225226.3c45e047@Tarkus> +References: + <20240503225226.3c45e047@Tarkus> +Message-ID: + +Ivan, thank you for the tips; they allowed me to move on to the next problems. +By building the tar file first and checking it later, and fixing several other problems I got +R CMD check to work. It does *not* delete inst/doc. It also does not run boostrap.R, +as far as I can tell, presumably because only devtools does. + +Check within RStudio continues to delete inst/doc, so this behavior is probably coming from +RStudio, devtools, or one the packages it invokes. The devtools::check() documentation +mentions it invoke pkgbuild::build() and rcmdcheck::rcmdcheck(). Since I'm guessing my command +line build and check invoked those last 2, or at least operated similarly, they seem less likely suspects. + +As I think I already mentioned, bootstrap.R when run outside of a check, but inside RStudio, also does not delete inst/doc. + +Anyway, there a lot of moving parts. Does anybody have any ideas? Deleting the directory just seems weird and so it's hard +to know where to look. + +Thanks. +Ross + +-----Original Message----- +From: Ivan Krylov +Sent: Friday, May 3, 2024 12:52 PM +To: Boylan, Ross via R-help +Cc: Boylan, Ross +Subject: Re: [R] R CMD check vs RStudio check + +? Fri, 3 May 2024 19:45:08 +0000 +"Boylan, Ross via R-help" ?????: + +> & $R CMD check . + +> * checking for file './DESCRIPTION' ... ERROR Required fields missing +> or empty: +> 'Author' 'Maintainer' + +You're checking a source package directory. This could work, but it's much easier and more reliable to (1) build a source tarball using R CMD build and (2) check the tarball. This is probably part of what +devtools::check() does. (It can also do a lot of other things pre-R CMD +build.) + +The reason checking the source directory is failing is because it's R CMD build that creates the necessary 'Author' and 'Maintainer' fields from Authors at R in your DESCRIPTION. + +> P.S. What's with the "..Rcheck" log directory, which appears literally +> with the 2 dots? Is this just MS-Windows getting confused and not +> interpreting .. as the parent directory? + +"..Rcheck" is built from the argument of R CMD check . followed by ".Rcheck". + +-- +Best regards, +Ivan + +From ru|pb@rr@d@@ @end|ng |rom @@po@pt Fri May 10 12:12:30 2024 +From: ru|pb@rr@d@@ @end|ng |rom @@po@pt (Rui Barradas) +Date: Fri, 10 May 2024 11:12:30 +0100 +Subject: [R] Print date on y axis with month, day, and year +In-Reply-To: +References: +Message-ID: + +?s 00:58 de 10/05/2024, Sorkin, John escreveu: +> I am trying to use ggplot to plot the data, and R code, below. The dates (jdate) are printing as Mar 01, Mar 15, etc. I want to have the date printed as MMM DD YYYY (or any other way that will show month, date, and year, e.g. mm/dd/yy). How can I accomplish this? +> +> yyy <- structure(list( +> jdate = structure(c(19052, 19053, 19054, 19055, +> 19058, 19059, 19060, 19061, 19062, 19063, 19065, 19066, 19067, +> 19068, 19069, 19072, 19073, 19074, 19075, 19076, 19077, 19083, +> 19086, 19087, 19088, 19089, 19090, 19093, 19094, 19095), class = "Date"), +> Sum = c ( 1, 3, 9, 11, 13, 16, 18, 22, 26, 27, 30, 32, 35, 39, 41, +> 43, 48, 51, 56, 58, 59, 63, 73, 79, 81, 88, 91, 93, 96, 103)), +> row.names = c(NA, 30L), class = "data.frame") +> yyy +> class(yyy$jdate) +> ggplot(data=yyy[1:30,],aes(as.Date(jdate,format="%m-%d-%Y"),Sum)) +geom_point() +> +> +> Thank you +> John +> +> +> +> John David Sorkin M.D., Ph.D. +> Professor of Medicine, University of Maryland School of Medicine; +> Associate Director for Biostatistics and Informatics, Baltimore VA Medical Center Geriatrics Research, Education, and Clinical Center; +> PI?Biostatistics and Informatics Core, University of Maryland School of Medicine Claude D. Pepper Older Americans Independence Center; +> Senior Statistician University of Maryland Center for Vascular Research; +> +> Division of Gerontology and Paliative Care, +> 10 North Greene Street +> GRECC (BT/18/GR) +> Baltimore, MD 21201-1524 +> Cell phone 443-418-5382 +> +> +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. +Hello, + +Since class(yyy$jdate) returns "Date", you have a real date and +scale_x_date can handle the printed formats, there is no need for an +extra as.Date in aes(). And get rid of the format = "%m-%d-%Y" argument. + +Let scale_x_date take care of formating the date as you want it +displayed. Any of the two below is a valid date format. + + + +ggplot(data = yyy[1:30,], aes(jdate, Sum)) + + geom_point() + + # scale_x_date(date_labels = "%b %d, %Y") + scale_x_date(date_labels = "%m/%d/%Y") + + + +Hope this helps, + +Rui Barradas + + + +-- +Este e-mail foi analisado pelo software antiv?rus AVG para verificar a presen?a de v?rus. +www.avg.com + + +From |kry|ov @end|ng |rom d|@root@org Fri May 10 17:45:03 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 10 May 2024 18:45:03 +0300 +Subject: [R] R CMD check vs RStudio check +In-Reply-To: +References: + <20240503225226.3c45e047@Tarkus> + +Message-ID: <20240510184503.3ed802e5@Tarkus> + +? Fri, 10 May 2024 03:46:54 +0000 +"Boylan, Ross" ?????: + +> The devtools::check() documentation mentions it invoke +> pkgbuild::build() and rcmdcheck::rcmdcheck(). Since I'm guessing my +> command line build and check invoked those last 2, or at least +> operated similarly, they seem less likely suspects. + +You are correct, it's part of what pkgbuild::build() does: + +https://search.r-project.org/CRAN/refmans/pkgbuild/html/build.html#clean_doc + +>> DESCRIPTION entries +>> +>> Config/build/clean-inst-doc can be set to FALSE to avoid cleaning +>> up inst/doc when building a source package. Set it to TRUE to force +>> a cleanup. See the clean_doc argument. + +(I didn't know that either, just searched their source code for +"inst.*doc".) + +-- +Best regards, +Ivan + + +From |kry|ov @end|ng |rom d|@root@org Sun May 12 17:54:33 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Sun, 12 May 2024 18:54:33 +0300 +Subject: [R] duplicated() on zero-column data frames returns empty +In-Reply-To: +References: + +Message-ID: <20240512185433.7039789b@Tarkus> + +(Sorry for only getting back to this more than a month later.) + +? Mon, 8 Apr 2024 17:03:00 +0000 +Jorgen Harmse ?????: + +> What is the policy for changing something that is wrong? There is a +> trade-off between breaking old code that worked around a problem and +> breaking new code written by people who make reasonable assumptions. + +First of all, quantify the breakage. Does the proposed change break +`make check-devel`? Does it break CRAN and BioConductor? (This one is +hard to measure properly: someone will have to run >20000 R CMD checks +times two, for "before the change" and "after the change".) Given a +persuasive case, breaking changes can still be made, but will require a +deprecation period to let the packages adjust. + +If you would like to try your hand at developing a patch and make a +case for it at R-devel or the Bugzilla, the resources at + can be helpful. + +-- +Best regards, +Ivan + + +From |@go@g|ne @end|ng |rom @jd@e@ Mon May 13 10:50:29 2024 +From: |@go@g|ne @end|ng |rom @jd@e@ (=?iso-8859-1?Q?Iago_Gin=E9_V=E1zquez?=) +Date: Mon, 13 May 2024 08:50:29 +0000 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: <20240508095832.7886e41c@rolf-Latitude-E7470> +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + + <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> + <20240508095832.7886e41c@rolf-Latitude-E7470> +Message-ID: + +Hi all, + +I've just could test your suggestions on using dataedit... entries now, and indeed they work... partially. See, please, the next screenshot: +https://ibb.co/Dkn2pVs + + +dataedituser modifies the red borders +dataedittext the yellow text +dataeditfg... I do not know, specified to green the output of View(mtcars) does not change from that of the screenshot +dataeditbg is the (almost) black background...., but in the column and row names. + +I tried the modifying the different colours through the GUI preferences, and the background colour for column and row names did not change. May this be a bug? + + +Thank you for your help. + +Best regards, + +Iago +________________________________ +De: Rolf Turner +Enviat el: dimarts, 7 de maig de 2024 23:58 +Per a: Duncan Murdoch +A/c: Iago Gin? V?zquez ; r-help at r-project.org ; Achim Zeileis +Tema: Re: [R] Is there some way to customize colours for the View output? + + +On Tue, 7 May 2024 06:34:50 -0400 +Duncan Murdoch wrote: + +> On 07/05/2024 6:31 a.m., Iago Gin? V?zquez wrote: +> > Thanks Duncan. +> > +> > I am currently on Windows. Is there any solution for it? +> +> Switch to Linux or MacOS? + + +Fortune nomination! + +cheers, + +Rolf Turner + +-- +Honorary Research Fellow +Department of Statistics +University of Auckland +Stats. Dep't. (secretaries) phone: + +64-9-373-7599 ext. 89622 +Home phone: +64-9-480-4619 + + + [[alternative HTML version deleted]] + + +From m@rkweb@ter204 @end|ng |rom y@hoo@co@uk Mon May 13 11:06:46 2024 +From: m@rkweb@ter204 @end|ng |rom y@hoo@co@uk (Mark Webster) +Date: Mon, 13 May 2024 09:06:46 +0000 (UTC) +Subject: [R] duplicated() on zero-column data frames returns empty +In-Reply-To: <20240512185433.7039789b@Tarkus> +References: + + <20240512185433.7039789b@Tarkus> +Message-ID: <164355257.2291177.1715591206553@mail.yahoo.com> + + >?If you would like to try your hand at developing a patch and make a +> case for it at R-devel or the Bugzilla, the resources at +> can be helpful. +I am attempting to get admitted onto the Bugzilla at the moment for the data frame cases, fingers crossed! +Best Regards,Mark Webster + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Mon May 13 12:08:22 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Mon, 13 May 2024 06:08:22 -0400 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + + <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> + <20240508095832.7886e41c@rolf-Latitude-E7470> + +Message-ID: + +I just tried it on an old Windows computer. I don't see dataeditfg in +the preferences menu; I think it is the internal variable name used for +"dataedittext". + +The row and column names don't appear to be controllable from that menu, +they seem (on my machine) to be displayed in the same colour as the +background of a dialog box, i.e. some kind of gray. I don't think R +tries to control that colour, but perhaps some Windows setting would +change it. + +Duncan Murdoch + +On 2024-05-13 4:50 a.m., Iago Gin? V?zquez wrote: +> Hi all, +> +> I've just could test your suggestions on using dataedit... entries now, +> and indeed they work... partially. See, please, the next screenshot: +> https://ibb.co/Dkn2pVs +> +> +> dataedituser modifies the red borders +> dataedittext the yellow text +> dataeditfg... I do not know, specified to green the output of +> View(mtcars) does not change from that of the screenshot +> dataeditbg is the (almost) black background...., but in the column and +> row names. +> +> I tried the modifying the different colours through the GUI preferences, +> and the background colour for column and row names did not change. May +> this be a bug? +> +> +> Thank you for your help. +> +> Best regards, +> +> Iago +> ------------------------------------------------------------------------ +> *De:* Rolf Turner +> *Enviat el:* dimarts, 7 de maig de 2024 23:58 +> *Per a:* Duncan Murdoch +> *A/c:* Iago Gin? V?zquez ; r-help at r-project.org +> ; Achim Zeileis +> *Tema:* Re: [R] Is there some way to customize colours for the View output? +> +> On Tue, 7 May 2024 06:34:50 -0400 +> Duncan Murdoch wrote: +> +>> On 07/05/2024 6:31 a.m., Iago Gin? V?zquez wrote: +>> > Thanks Duncan. +>> > +>> > I am currently on Windows. Is there any solution for it? +>> +>> Switch to Linux or MacOS? +> +> +> Fortune nomination! +> +> cheers, +> +> Rolf Turner +> +> -- +> Honorary Research Fellow +> Department of Statistics +> University of Auckland +> Stats. Dep't. (secretaries) phone: +> ???????? +64-9-373-7599 ext. 89622 +> Home phone: +64-9-480-4619 +> + + +From |kry|ov @end|ng |rom d|@root@org Mon May 13 14:34:35 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Mon, 13 May 2024 15:34:35 +0300 +Subject: [R] Is there some way to customize colours for the View output? +In-Reply-To: +References: + <6fd81bdd-4e7e-4736-b71d-f71c402d5cfa@gmail.com> + + <1fd3aba6-1da9-4d6a-804b-13a70cb9f096@gmail.com> + <20240508095832.7886e41c@rolf-Latitude-E7470> + + +Message-ID: <20240513153435.2a735f2c@arachnoid> + +? Mon, 13 May 2024 06:08:22 -0400 +Duncan Murdoch ?????: + +> The row and column names don't appear to be controllable from that +> menu, they seem (on my machine) to be displayed in the same colour as +> the background of a dialog box, i.e. some kind of gray. I don't +> think R tries to control that colour, but perhaps some Windows +> setting would change it. + +This is entirely correct: the dialog uses the colour returned by +dialog_bg(), which is GetSysColor(COLOR_BTNFACE). + +I think it could be a reasonable feature request to use an adjustable +colour for the row and column headers. + +-- +Best regards, +Ivan + + +From r|k|v|||@|b@ @end|ng |rom gm@||@com Mon May 13 16:37:57 2024 +From: r|k|v|||@|b@ @end|ng |rom gm@||@com (Ricardo Villalba) +Date: Mon, 13 May 2024 11:37:57 -0300 +Subject: [R] Description of error is untranslated when R_XLEN_T_MAX is + exceeded by only 1 element. +Message-ID: + +Hello everyone +When asking to create sequence longer than 2^48 (which is forbidden) the +same error message appears translated and untranslated depending on whether +R_XLEN_T_MAX is reached or exceeded +while not an error o problem beyond that of the untranslated text, i find +this weird. ?could it be fixed in any manner? + +R_XLEN_T_MAX <- 4503599627370496 + +> length(1:(R_XLEN_T_MAX - 1)) +[1] 4.5036e+15 +> length(1:(R_XLEN_T_MAX + 0)) +Error: result would be too long a vector +> length(1:(R_XLEN_T_MAX + 1)) +Error en 1:(R_XLEN_T_MAX + 1): el resultado seria un vector muy largo + +The last is the same as the second, but translated into spanish. + +I track the messages to be coded here: +https://github.com/r-devel/r-svn/blob/abe625945c4402cd2bb97b5a64e7469db3e904f0/src/main/altclasses.c#L580 +and +here +https://github.com/r-devel/r-svn/blob/abe625945c4402cd2bb97b5a64e7469db3e904f0/src/main/seq.c#L102 + +-- +?DV! + + [[alternative HTML version deleted]] + + +From r|k|v|||@|b@ @end|ng |rom gm@||@com Mon May 13 16:39:11 2024 +From: r|k|v|||@|b@ @end|ng |rom gm@||@com (Ricardo Villalba) +Date: Mon, 13 May 2024 11:39:11 -0300 +Subject: [R] Description of error is untranslated when R_XLEN_T_MAX is + exceeded by only 1 element. +In-Reply-To: +References: +Message-ID: + +Typo: *2^48 should be 2^52 + +El lun, 13 may 2024 a las 11:37, Ricardo Villalba () +escribi?: + +> Hello everyone +> When asking to create sequence longer than 2^48 (which is forbidden) the +> same error message appears translated and untranslated depending on whether +> R_XLEN_T_MAX is reached or exceeded +> while not an error o problem beyond that of the untranslated text, i find +> this weird. ?could it be fixed in any manner? +> +> R_XLEN_T_MAX <- 4503599627370496 +> +> > length(1:(R_XLEN_T_MAX - 1)) +> [1] 4.5036e+15 +> > length(1:(R_XLEN_T_MAX + 0)) +> Error: result would be too long a vector +> > length(1:(R_XLEN_T_MAX + 1)) +> Error en 1:(R_XLEN_T_MAX + 1): el resultado seria un vector muy largo +> +> The last is the same as the second, but translated into spanish. +> +> I track the messages to be coded here: +> https://github.com/r-devel/r-svn/blob/abe625945c4402cd2bb97b5a64e7469db3e904f0/src/main/altclasses.c#L580 and +> here +> https://github.com/r-devel/r-svn/blob/abe625945c4402cd2bb97b5a64e7469db3e904f0/src/main/seq.c#L102 +> +> -- +> ?DV! +> + + +-- +?DV! + + [[alternative HTML version deleted]] + + +From JH@rm@e @end|ng |rom roku@com Mon May 13 22:13:49 2024 +From: JH@rm@e @end|ng |rom roku@com (Jorgen Harmse) +Date: Mon, 13 May 2024 20:13:49 +0000 +Subject: [R] + [EXTERNAL] Re: duplicated() on zero-column data frames returns empty +In-Reply-To: <164355257.2291177.1715591206553@mail.yahoo.com> +References: + + <20240512185433.7039789b@Tarkus> + <164355257.2291177.1715591206553@mail.yahoo.com> +Message-ID: + +Good luck! It looks like a significant effort for someone not already on the team. + +Regards, +Jorgen Harmse. + +From: Mark Webster +Date: Monday, May 13, 2024 at 04:07 +To: Jorgen Harmse , Ivan Krylov +Cc: r-help at r-project.org +Subject: [EXTERNAL] Re: duplicated() on zero-column data frames returns empty +> If you would like to try your hand at developing a patch and make a +> case for it at R-devel or the Bugzilla, the resources at +> can be helpful. + +I am attempting to get admitted onto the Bugzilla at the moment for the data frame cases, fingers crossed! + +Best Regards, +Mark Webster + + [[alternative HTML version deleted]] + + +From ju@t|ne@@|||g@nd @end|ng |rom @tudent@un|-@|egen@de Mon May 13 18:24:25 2024 +From: ju@t|ne@@|||g@nd @end|ng |rom @tudent@un|-@|egen@de (Alligand, Justine) +Date: Mon, 13 May 2024 16:24:25 +0000 +Subject: [R] test2r.mengz1(X) +Message-ID: <8234a274c2674b478d7646b6bc82c070@student.uni-siegen.de> + +Dear participants and subscribers of the R-help mailing list, + +I would like to compare two dependent correlations with one overlapping variable. The Meng Z1 method seemed suitable for this purpose. I found out that the "cocor" package is required for this instrument. I checked several times whether the package was installed and activated and both were the case. I have also tried the "psych" package, but I get the same error in both cases: +> library(cocor) +> library(psych) +> test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) +Error in test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) : + could not find function "test2r.mengz1" (Translated from German) +Do I not have the right package? Or can you recognize another error? +Many thanks in advance. + +Yours faithfully +Justine Alligand + + + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Mon May 13 22:53:49 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Mon, 13 May 2024 16:53:49 -0400 +Subject: [R] test2r.mengz1(X) +In-Reply-To: <8234a274c2674b478d7646b6bc82c070@student.uni-siegen.de> +References: <8234a274c2674b478d7646b6bc82c070@student.uni-siegen.de> +Message-ID: + +Google says that function is in the bcdstats package, which isn't on +CRAN. It appears to be a private package for a course, kept on Github. + +Duncan Murdoch + +On 2024-05-13 12:24 p.m., Alligand, Justine wrote: +> Dear participants and subscribers of the R-help mailing list, +> +> I would like to compare two dependent correlations with one overlapping variable. The Meng Z1 method seemed suitable for this purpose. I found out that the "cocor" package is required for this instrument. I checked several times whether the package was installed and activated and both were the case. I have also tried the "psych" package, but I get the same error in both cases: +>> library(cocor) +>> library(psych) +>> test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) +> Error in test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) : +> could not find function "test2r.mengz1" (Translated from German) +> Do I not have the right package? Or can you recognize another error? +> Many thanks in advance. +> +> Yours faithfully +> Justine Alligand +> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + +From bgunter@4567 @end|ng |rom gm@||@com Mon May 13 23:00:30 2024 +From: bgunter@4567 @end|ng |rom gm@||@com (Bert Gunter) +Date: Mon, 13 May 2024 14:00:30 -0700 +Subject: [R] test2r.mengz1(X) +In-Reply-To: +References: <8234a274c2674b478d7646b6bc82c070@student.uni-siegen.de> + +Message-ID: + +... but maybe cocor() in the cocor package will do do what you want. + +-- Bert + + +On Mon, May 13, 2024 at 1:57?PM Duncan Murdoch wrote: +> +> Google says that function is in the bcdstats package, which isn't on +> CRAN. It appears to be a private package for a course, kept on Github. +> +> Duncan Murdoch +> +> On 2024-05-13 12:24 p.m., Alligand, Justine wrote: +> > Dear participants and subscribers of the R-help mailing list, +> > +> > I would like to compare two dependent correlations with one overlapping variable. The Meng Z1 method seemed suitable for this purpose. I found out that the "cocor" package is required for this instrument. I checked several times whether the package was installed and activated and both were the case. I have also tried the "psych" package, but I get the same error in both cases: +> >> library(cocor) +> >> library(psych) +> >> test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) +> > Error in test2r.mengz1(corAVOBMI, corAVVBMI, corAVOAVV, 39) : +> > could not find function "test2r.mengz1" (Translated from German) +> > Do I not have the right package? Or can you recognize another error? +> > Many thanks in advance. +> > +> > Yours faithfully +> > Justine Alligand +> > +> > +> > [[alternative HTML version deleted]] +> > +> > ______________________________________________ +> > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> > https://stat.ethz.ch/mailman/listinfo/r-help +> > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> > and provide commented, minimal, self-contained, reproducible code. +> +> ______________________________________________ +> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see +> https://stat.ethz.ch/mailman/listinfo/r-help +> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html +> and provide commented, minimal, self-contained, reproducible code. + + diff --git a/r-package-devel/2024q2.txt b/r-package-devel/2024q2.txt index 0517f65..a4c5b8a 100644 --- a/r-package-devel/2024q2.txt +++ b/r-package-devel/2024q2.txt @@ -2174,3 +2174,8644 @@ On 13/04/2024 5:35 a.m., Tony Wilkes wrote: > https://stat.ethz.ch/mailman/listinfo/r-package-devel +From bbo|ker @end|ng |rom gm@||@com Thu Apr 18 15:04:34 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 18 Apr 2024 09:04:34 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +Message-ID: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + The 'dotwhisker' package was archived on CRAN: from +https://cran.r-project.org/web/packages/dotwhisker/index.html + + Package ?dotwhisker? was removed from the CRAN repository + ... + + Archived on 2024-04-12 as requires archived package 'prediction'. + + However, I can't for the life of me see where this dependence could +come from. Neither the DESCRIPTION file of the last-archived version on +CRAN +, +nor the version on github , seem to +show any signs of importing prediction ... ?? I suppose there's a +possibility of a recursive dependence, but in that case why wouldn't the +direct dependence be reported? + +Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +Imports: grid, gtable, gridExtra, stats, parameters, performance, + patchwork, margins, dplyr, stringr, ggstance, rlang, purrr +Suggests: ordinal, tibble, knitr, rmarkdown, broom + + What am I missing? + + (I'm concerned because I have packages that Suggest: dotwhisker, and +the absence of the package from repos is breaking GitHub Actions checks ...) + + + (This is cross-posted from an issue on the dotwhisker GH repository: +https://github.com/fsolt/dotwhisker/issues/115) + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Thu Apr 18 15:11:03 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Thu, 18 Apr 2024 09:11:03 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> +Message-ID: + +Well, after trying to install the package, I believe the issue is because +margins has been archived. + +https://cran.r-project.org/web/packages/margins/index.html + +You can check recursive dependencies using +`tools::package_dependencies("pkg", recursive = TRUE)` which would help you +in this case. I couldn't run it since the package is not available on CRAN, +however. + + +On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker wrote: + +> The 'dotwhisker' package was archived on CRAN: from +> https://cran.r-project.org/web/packages/dotwhisker/index.html +> +> Package ?dotwhisker? was removed from the CRAN repository +> ... +> +> Archived on 2024-04-12 as requires archived package 'prediction'. +> +> However, I can't for the life of me see where this dependence could +> come from. Neither the DESCRIPTION file of the last-archived version on +> CRAN +> < +> https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz>, +> +> nor the version on github , seem to +> show any signs of importing prediction ... ?? I suppose there's a +> possibility of a recursive dependence, but in that case why wouldn't the +> direct dependence be reported? +> +> Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +> Imports: grid, gtable, gridExtra, stats, parameters, performance, +> patchwork, margins, dplyr, stringr, ggstance, rlang, purrr +> Suggests: ordinal, tibble, knitr, rmarkdown, broom +> +> What am I missing? +> +> (I'm concerned because I have packages that Suggest: dotwhisker, and +> the absence of the package from repos is breaking GitHub Actions checks +> ...) +> +> +> (This is cross-posted from an issue on the dotwhisker GH repository: +> https://github.com/fsolt/dotwhisker/issues/115) +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From bbo|ker @end|ng |rom gm@||@com Thu Apr 18 15:14:46 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 18 Apr 2024 09:14:46 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + +Message-ID: + + Thank you! (I know about package_dependencies() but ran into +precisely the same problem and didn't want to re-implement it ...) + +On 2024-04-18 9:11 a.m., Josiah Parry wrote: +> Well, after trying to install the package, I believe the issue is +> because margins has been archived. +> +> https://cran.r-project.org/web/packages/margins/index.html +> +> +> You can check recursive dependencies using +> `tools::package_dependencies("pkg", recursive = TRUE)` which would help +> you in this case. I couldn't run it since the package is not available +> on CRAN, however. +> +> +> On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker > wrote: +> +> ? ?The 'dotwhisker' package was archived on CRAN: from +> https://cran.r-project.org/web/packages/dotwhisker/index.html +> +> +> ? ? ?Package ?dotwhisker? was removed from the CRAN repository +> ? ? ?... +> +> ? ? ?Archived on 2024-04-12 as requires archived package 'prediction'. +> +> ? ? However, I can't for the life of me see where this dependence +> could +> come from. Neither the DESCRIPTION file of the last-archived version on +> CRAN +> >, +> nor the version on github >, seem to +> show any signs of importing prediction ... ?? I suppose there's a +> possibility of a recursive dependence, but in that case why wouldn't +> the +> direct dependence be reported? +> +> Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +> Imports: grid, gtable, gridExtra, stats, parameters, performance, +> ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, rlang, purrr +> Suggests: ordinal, tibble, knitr, rmarkdown, broom +> +> ? ?What am I missing? +> +> ? ?(I'm concerned because I have packages that Suggest: dotwhisker, +> and +> the absence of the package from repos is breaking GitHub Actions +> checks ...) +> +> +> ? ?(This is cross-posted from an issue on the dotwhisker GH +> repository: +> https://github.com/fsolt/dotwhisker/issues/115 +> ) +> +> ______________________________________________ +> R-package-devel at r-project.org +> mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> +> + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From th|erry@onke||nx @end|ng |rom |nbo@be Thu Apr 18 15:28:24 2024 +From: th|erry@onke||nx @end|ng |rom |nbo@be (Thierry Onkelinx) +Date: Thu, 18 Apr 2024 15:28:24 +0200 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + +Message-ID: + +The cascade is even longer. prediction got archived because ffbase was no +longer available. https://cran.r-project.org/web/packages/ffbase/ + +ir. Thierry Onkelinx +Statisticus / Statistician + +Vlaamse Overheid / Government of Flanders +INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND +FOREST +Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +thierry.onkelinx at inbo.be +Havenlaan 88 bus 73, 1000 Brussel +*Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +*Poststukken die naar dit adres worden gestuurd, worden ingescand en +digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +dossiers volledig digitaal behandelen. Poststukken met de vermelding +?vertrouwelijk? worden niet ingescand, maar ongeopend aan de geadresseerde +bezorgd.* +www.inbo.be + +/////////////////////////////////////////////////////////////////////////////////////////// +To call in the statistician after the experiment is done may be no more +than asking him to perform a post-mortem examination: he may be able to say +what the experiment died of. ~ Sir Ronald Aylmer Fisher +The plural of anecdote is not data. ~ Roger Brinner +The combination of some data and an aching desire for an answer does not +ensure that a reasonable answer can be extracted from a given body of data. +~ John Tukey +/////////////////////////////////////////////////////////////////////////////////////////// + + + + +Op do 18 apr 2024 om 15:25 schreef Ben Bolker : + +> Thank you! (I know about package_dependencies() but ran into +> precisely the same problem and didn't want to re-implement it ...) +> +> On 2024-04-18 9:11 a.m., Josiah Parry wrote: +> > Well, after trying to install the package, I believe the issue is +> > because margins has been archived. +> > +> > https://cran.r-project.org/web/packages/margins/index.html +> > +> > +> > You can check recursive dependencies using +> > `tools::package_dependencies("pkg", recursive = TRUE)` which would help +> > you in this case. I couldn't run it since the package is not available +> > on CRAN, however. +> > +> > +> > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker > > wrote: +> > +> > The 'dotwhisker' package was archived on CRAN: from +> > https://cran.r-project.org/web/packages/dotwhisker/index.html +> > +> > +> > Package ?dotwhisker? was removed from the CRAN repository +> > ... +> > +> > Archived on 2024-04-12 as requires archived package +> 'prediction'. +> > +> > However, I can't for the life of me see where this dependence +> > could +> > come from. Neither the DESCRIPTION file of the last-archived version +> on +> > CRAN +> > < +> https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz +> < +> https://cran.r-project.org/src/contrib/Archive/dotwhisker/dotwhisker_0.8.1.tar.gz +> >>, +> > nor the version on github > >, seem to +> > show any signs of importing prediction ... ?? I suppose there's a +> > possibility of a recursive dependence, but in that case why wouldn't +> > the +> > direct dependence be reported? +> > +> > Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +> > Imports: grid, gtable, gridExtra, stats, parameters, performance, +> > patchwork, margins, dplyr, stringr, ggstance, rlang, purrr +> > Suggests: ordinal, tibble, knitr, rmarkdown, broom +> > +> > What am I missing? +> > +> > (I'm concerned because I have packages that Suggest: dotwhisker, +> > and +> > the absence of the package from repos is breaking GitHub Actions +> > checks ...) +> > +> > +> > (This is cross-posted from an issue on the dotwhisker GH +> > repository: +> > https://github.com/fsolt/dotwhisker/issues/115 +> > ) +> > +> > ______________________________________________ +> > R-package-devel at r-project.org +> > mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-package-devel +> > +> > +> +> -- +> Dr. Benjamin Bolker +> Professor, Mathematics & Statistics and Biology, McMaster University +> Director, School of Computational Science and Engineering +> (Acting) Graduate chair, Mathematics & Statistics +> > E-mail is sent at my convenience; I don't expect replies outside of +> working hours. +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From bbo|ker @end|ng |rom gm@||@com Thu Apr 18 15:35:32 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 18 Apr 2024 09:35:32 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + +Message-ID: + + Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +has apparently just caught up to checking. What's a little frustrating +(to me) is that the dependence of prediction on ffbase is *very* soft +("enhances") ... + +On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +> The cascade is even longer. prediction got archived because ffbase was +> no longer available. https://cran.r-project.org/web/packages/ffbase/ +> +> +> ir. Thierry Onkelinx +> Statisticus / Statistician +> +> Vlaamse Overheid / Government of Flanders +> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE +> AND FOREST +> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +> thierry.onkelinx at inbo.be +> Havenlaan 88 bus 73, 1000 Brussel +> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +> dossiers volledig digitaal behandelen. Poststukken met de vermelding +> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de +> geadresseerde bezorgd./ +> www.inbo.be +> +> /////////////////////////////////////////////////////////////////////////////////////////// +> To call in the statistician after the experiment is done may be no more +> than asking him to perform a post-mortem examination: he may be able to +> say what the experiment died of. ~ Sir Ronald Aylmer Fisher +> The plural of anecdote is not data. ~ Roger Brinner +> The combination of some data and an aching desire for an answer does not +> ensure that a reasonable answer can be extracted from a given body of +> data. ~ John Tukey +> /////////////////////////////////////////////////////////////////////////////////////////// +> +> +> +> +> Op do 18 apr 2024 om 15:25 schreef Ben Bolker >: +> +> ? ?Thank you! (I know about package_dependencies() but ran into +> precisely the same problem and didn't want to re-implement it ...) +> +> On 2024-04-18 9:11 a.m., Josiah Parry wrote: +> > Well, after trying to install the package, I believe the issue is +> > because margins has been archived. +> > +> > https://cran.r-project.org/web/packages/margins/index.html +> +> > > +> > +> > You can check recursive dependencies using +> > `tools::package_dependencies("pkg", recursive = TRUE)` which +> would help +> > you in this case. I couldn't run it since the package is not +> available +> > on CRAN, however. +> > +> > +> > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker +> > >> wrote: +> > +> >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +> > https://cran.r-project.org/web/packages/dotwhisker/index.html +> +> > +> ? > +> > +> >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN repository +> >? ? ? ? ? ?... +> > +> >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +> 'prediction'. +> > +> >? ? ? ? ? However, I can't for the life of me see where this +> dependence +> >? ? ?could +> >? ? ?come from. Neither the DESCRIPTION file of the last-archived +> version on +> >? ? ?CRAN +> > +> ? >>, +> >? ? ?nor the version on github +> +> >? ? ? >>, seem to +> >? ? ?show any signs of importing prediction ... ?? I suppose there's a +> >? ? ?possibility of a recursive dependence, but in that case why +> wouldn't +> >? ? ?the +> >? ? ?direct dependence be reported? +> > +> >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +> >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, performance, +> >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +> rlang, purrr +> >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +> > +> >? ? ? ? ?What am I missing? +> > +> >? ? ? ? ?(I'm concerned because I have packages that Suggest: +> dotwhisker, +> >? ? ?and +> >? ? ?the absence of the package from repos is breaking GitHub Actions +> >? ? ?checks ...) +> > +> > +> >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +> >? ? ?repository: +> > https://github.com/fsolt/dotwhisker/issues/115 +> +> >? ? ? >) +> > +> >? ? ?______________________________________________ +> > R-package-devel at r-project.org +> +> > +> >? ? ?mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-package-devel +> +> >? ? ? > +> > +> +> -- +> Dr. Benjamin Bolker +> Professor, Mathematics & Statistics and Biology, McMaster University +> Director, School of Computational Science and Engineering +> (Acting) Graduate chair, Mathematics & Statistics +> ?> E-mail is sent at my convenience; I don't expect replies outside of +> working hours. +> +> ______________________________________________ +> R-package-devel at r-project.org +> mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> +> + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de Thu Apr 18 15:41:18 2024 +From: ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de (Uwe Ligges) +Date: Thu, 18 Apr 2024 15:41:18 +0200 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + +Message-ID: + + + +On 18.04.2024 15:35, Ben Bolker wrote: +> ?? Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +> has apparently just caught up to checking.? What's a little frustrating +> (to me) is that the dependence of prediction on ffbase is *very* soft +> ("enhances") ... + +No, but CRAN has still not received an update and asked for this each +month this year, so in Jan, Feb, and March without a response, so we +assume prediction is unmaintained. Also, this was escalated to reverse +depends. + +Best, +Uwe Ligges + + +> +> On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +>> The cascade is even longer. prediction got archived because ffbase was +>> no longer available. https://cran.r-project.org/web/packages/ffbase/ +>> +>> +>> ir. Thierry Onkelinx +>> Statisticus / Statistician +>> +>> Vlaamse Overheid / Government of Flanders +>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE +>> AND FOREST +>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +>> thierry.onkelinx at inbo.be +>> Havenlaan 88 bus 73, 1000 Brussel +>> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +>> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +>> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +>> dossiers volledig digitaal behandelen. Poststukken met de vermelding +>> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de +>> geadresseerde bezorgd./ +>> www.inbo.be +>> +>> /////////////////////////////////////////////////////////////////////////////////////////// +>> To call in the statistician after the experiment is done may be no +>> more than asking him to perform a post-mortem examination: he may be +>> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +>> The plural of anecdote is not data. ~ Roger Brinner +>> The combination of some data and an aching desire for an answer does +>> not ensure that a reasonable answer can be extracted from a given body +>> of data. ~ John Tukey +>> /////////////////////////////////////////////////////////////////////////////////////////// +>> +>> +>> +>> +>> Op do 18 apr 2024 om 15:25 schreef Ben Bolker > >: +>> +>> ???? ? ?Thank you! (I know about package_dependencies() but ran into +>> ??? precisely the same problem and didn't want to re-implement it ...) +>> +>> ??? On 2024-04-18 9:11 a.m., Josiah Parry wrote: +>> ???? > Well, after trying to install the package, I believe the issue is +>> ???? > because margins has been archived. +>> ???? > +>> ???? > https://cran.r-project.org/web/packages/margins/index.html +>> ??? +>> ???? > > ??? > +>> ???? > +>> ???? > You can check recursive dependencies using +>> ???? > `tools::package_dependencies("pkg", recursive = TRUE)` which +>> ??? would help +>> ???? > you in this case. I couldn't run it since the package is not +>> ??? available +>> ???? > on CRAN, however. +>> ???? > +>> ???? > +>> ???? > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker > ??? +>> ???? > >> wrote: +>> ???? > +>> ???? >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +>> ???? > https://cran.r-project.org/web/packages/dotwhisker/index.html +>> ??? +>> ???? > +>> ?> ??? > +>> ???? > +>> ???? >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN +>> repository +>> ???? >? ? ? ? ? ?... +>> ???? > +>> ???? >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +>> ??? 'prediction'. +>> ???? > +>> ???? >? ? ? ? ? However, I can't for the life of me see where this +>> ??? dependence +>> ???? >? ? ?could +>> ???? >? ? ?come from. Neither the DESCRIPTION file of the last-archived +>> ??? version on +>> ???? >? ? ?CRAN +>> ???? > +>> ? >>, +>> ???? >? ? ?nor the version on github +>> ??? > ??? +>> ???? >? ? ?> ??? >>, seem to +>> ???? >? ? ?show any signs of importing prediction ... ?? I suppose +>> there's a +>> ???? >? ? ?possibility of a recursive dependence, but in that case why +>> ??? wouldn't +>> ???? >? ? ?the +>> ???? >? ? ?direct dependence be reported? +>> ???? > +>> ???? >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +>> ???? >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, +>> performance, +>> ???? >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +>> ??? rlang, purrr +>> ???? >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +>> ???? > +>> ???? >? ? ? ? ?What am I missing? +>> ???? > +>> ???? >? ? ? ? ?(I'm concerned because I have packages that Suggest: +>> ??? dotwhisker, +>> ???? >? ? ?and +>> ???? >? ? ?the absence of the package from repos is breaking GitHub +>> Actions +>> ???? >? ? ?checks ...) +>> ???? > +>> ???? > +>> ???? >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +>> ???? >? ? ?repository: +>> ???? > https://github.com/fsolt/dotwhisker/issues/115 +>> ??? +>> ???? >? ? ?> ??? >) +>> ???? > +>> ???? >? ? ?______________________________________________ +>> ???? > R-package-devel at r-project.org +>> ??? +>> ??? > ??? > +>> ???? >? ? ?mailing list +>> ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> ??? +>> ???? >? ? ?> ??? > +>> ???? > +>> +>> ??? -- ??? Dr. Benjamin Bolker +>> ??? Professor, Mathematics & Statistics and Biology, McMaster University +>> ??? Director, School of Computational Science and Engineering +>> ??? (Acting) Graduate chair, Mathematics & Statistics +>> ???? ?> E-mail is sent at my convenience; I don't expect replies +>> outside of +>> ??? working hours. +>> +>> ??? ______________________________________________ +>> ??? R-package-devel at r-project.org +>> ??? mailing list +>> ??? https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> ??? +>> +> + +From bbo|ker @end|ng |rom gm@||@com Thu Apr 18 15:43:29 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 18 Apr 2024 09:43:29 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + +Message-ID: + + To clarify, from an off-list conversation: + + AFAICT the chain is + + dotwhisker Imports + margins, which Imports + prediction, which Enhances + ffbase (archived in 2022 for 'coercion to logical' problems) + + (that conversation also pointed out that Enhances is a dependency *in +the opposite direction* -- i.e. if A Enhances B, it's not entirely clear +why the disappearance of B should matter at all ...) + + + +On 2024-04-18 9:35 a.m., Ben Bolker wrote: +> ?? Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +> has apparently just caught up to checking.? What's a little frustrating +> (to me) is that the dependence of prediction on ffbase is *very* soft +> ("enhances") ... +> +> On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +>> The cascade is even longer. prediction got archived because ffbase was +>> no longer available. https://cran.r-project.org/web/packages/ffbase/ +>> +>> +>> ir. Thierry Onkelinx +>> Statisticus / Statistician +>> +>> Vlaamse Overheid / Government of Flanders +>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE +>> AND FOREST +>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +>> thierry.onkelinx at inbo.be +>> Havenlaan 88 bus 73, 1000 Brussel +>> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +>> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +>> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +>> dossiers volledig digitaal behandelen. Poststukken met de vermelding +>> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de +>> geadresseerde bezorgd./ +>> www.inbo.be +>> +>> /////////////////////////////////////////////////////////////////////////////////////////// +>> To call in the statistician after the experiment is done may be no +>> more than asking him to perform a post-mortem examination: he may be +>> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +>> The plural of anecdote is not data. ~ Roger Brinner +>> The combination of some data and an aching desire for an answer does +>> not ensure that a reasonable answer can be extracted from a given body +>> of data. ~ John Tukey +>> /////////////////////////////////////////////////////////////////////////////////////////// +>> +>> +>> +>> +>> Op do 18 apr 2024 om 15:25 schreef Ben Bolker > >: +>> +>> ???? ? ?Thank you! (I know about package_dependencies() but ran into +>> ??? precisely the same problem and didn't want to re-implement it ...) +>> +>> ??? On 2024-04-18 9:11 a.m., Josiah Parry wrote: +>> ???? > Well, after trying to install the package, I believe the issue is +>> ???? > because margins has been archived. +>> ???? > +>> ???? > https://cran.r-project.org/web/packages/margins/index.html +>> ??? +>> ???? > > ??? > +>> ???? > +>> ???? > You can check recursive dependencies using +>> ???? > `tools::package_dependencies("pkg", recursive = TRUE)` which +>> ??? would help +>> ???? > you in this case. I couldn't run it since the package is not +>> ??? available +>> ???? > on CRAN, however. +>> ???? > +>> ???? > +>> ???? > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker > ??? +>> ???? > >> wrote: +>> ???? > +>> ???? >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +>> ???? > https://cran.r-project.org/web/packages/dotwhisker/index.html +>> ??? +>> ???? > +>> ?> ??? > +>> ???? > +>> ???? >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN +>> repository +>> ???? >? ? ? ? ? ?... +>> ???? > +>> ???? >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +>> ??? 'prediction'. +>> ???? > +>> ???? >? ? ? ? ? However, I can't for the life of me see where this +>> ??? dependence +>> ???? >? ? ?could +>> ???? >? ? ?come from. Neither the DESCRIPTION file of the last-archived +>> ??? version on +>> ???? >? ? ?CRAN +>> ???? > +>> ? >>, +>> ???? >? ? ?nor the version on github +>> ??? > ??? +>> ???? >? ? ?> ??? >>, seem to +>> ???? >? ? ?show any signs of importing prediction ... ?? I suppose +>> there's a +>> ???? >? ? ?possibility of a recursive dependence, but in that case why +>> ??? wouldn't +>> ???? >? ? ?the +>> ???? >? ? ?direct dependence be reported? +>> ???? > +>> ???? >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +>> ???? >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, +>> performance, +>> ???? >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +>> ??? rlang, purrr +>> ???? >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +>> ???? > +>> ???? >? ? ? ? ?What am I missing? +>> ???? > +>> ???? >? ? ? ? ?(I'm concerned because I have packages that Suggest: +>> ??? dotwhisker, +>> ???? >? ? ?and +>> ???? >? ? ?the absence of the package from repos is breaking GitHub +>> Actions +>> ???? >? ? ?checks ...) +>> ???? > +>> ???? > +>> ???? >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +>> ???? >? ? ?repository: +>> ???? > https://github.com/fsolt/dotwhisker/issues/115 +>> ??? +>> ???? >? ? ?> ??? >) +>> ???? > +>> ???? >? ? ?______________________________________________ +>> ???? > R-package-devel at r-project.org +>> ??? +>> ??? > ??? > +>> ???? >? ? ?mailing list +>> ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> ??? +>> ???? >? ? ?> ??? > +>> ???? > +>> +>> ??? -- ??? Dr. Benjamin Bolker +>> ??? Professor, Mathematics & Statistics and Biology, McMaster University +>> ??? Director, School of Computational Science and Engineering +>> ??? (Acting) Graduate chair, Mathematics & Statistics +>> ???? ?> E-mail is sent at my convenience; I don't expect replies +>> outside of +>> ??? working hours. +>> +>> ??? ______________________________________________ +>> ??? R-package-devel at r-project.org +>> ??? mailing list +>> ??? https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> ??? +>> +> + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From bbo|ker @end|ng |rom gm@||@com Thu Apr 18 15:47:20 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Thu, 18 Apr 2024 09:47:20 -0400 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + + +Message-ID: + + + +On 2024-04-18 9:41 a.m., Uwe Ligges wrote: +> +> +> On 18.04.2024 15:35, Ben Bolker wrote: +>> ??? Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +>> has apparently just caught up to checking.? What's a little +>> frustrating (to me) is that the dependence of prediction on ffbase is +>> *very* soft ("enhances") ... +> +> No, but CRAN? has still not received an update and asked for this each +> month this year, so in Jan, Feb, and March without a response, so we +> assume prediction is unmaintained. Also, this was escalated to reverse +> depends. +> +> Best, +> Uwe Ligges + + Fair enough. I'm not sure what the last sentence ("this was +escalated to reverse depends") means though ... + + FWIW I did get an e-mail response from the maintainer two days ago +suggesting that they were preparing a resubmission ... + +> +> +>> +>> On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +>>> The cascade is even longer. prediction got archived because ffbase +>>> was no longer available. +>>> https://cran.r-project.org/web/packages/ffbase/ +>>> +>>> +>>> ir. Thierry Onkelinx +>>> Statisticus / Statistician +>>> +>>> Vlaamse Overheid / Government of Flanders +>>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR +>>> NATURE AND FOREST +>>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +>>> thierry.onkelinx at inbo.be +>>> Havenlaan 88 bus 73, 1000 Brussel +>>> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +>>> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +>>> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid +>>> haar dossiers volledig digitaal behandelen. Poststukken met de +>>> vermelding ?vertrouwelijk? worden niet ingescand, maar ongeopend aan +>>> de geadresseerde bezorgd./ +>>> www.inbo.be +>>> +>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>> To call in the statistician after the experiment is done may be no +>>> more than asking him to perform a post-mortem examination: he may be +>>> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +>>> The plural of anecdote is not data. ~ Roger Brinner +>>> The combination of some data and an aching desire for an answer does +>>> not ensure that a reasonable answer can be extracted from a given +>>> body of data. ~ John Tukey +>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>> +>>> +>>> +>>> +>>> Op do 18 apr 2024 om 15:25 schreef Ben Bolker >> >: +>>> +>>> ???? ? ?Thank you! (I know about package_dependencies() but ran into +>>> ??? precisely the same problem and didn't want to re-implement it ...) +>>> +>>> ??? On 2024-04-18 9:11 a.m., Josiah Parry wrote: +>>> ???? > Well, after trying to install the package, I believe the issue is +>>> ???? > because margins has been archived. +>>> ???? > +>>> ???? > https://cran.r-project.org/web/packages/margins/index.html +>>> ??? +>>> ???? > >> ??? > +>>> ???? > +>>> ???? > You can check recursive dependencies using +>>> ???? > `tools::package_dependencies("pkg", recursive = TRUE)` which +>>> ??? would help +>>> ???? > you in this case. I couldn't run it since the package is not +>>> ??? available +>>> ???? > on CRAN, however. +>>> ???? > +>>> ???? > +>>> ???? > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker >> ??? +>>> ???? > >> wrote: +>>> ???? > +>>> ???? >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +>>> ???? > https://cran.r-project.org/web/packages/dotwhisker/index.html +>>> ??? +>>> ???? > ?>> ??? > +>>> ???? > +>>> ???? >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN +>>> repository +>>> ???? >? ? ? ? ? ?... +>>> ???? > +>>> ???? >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +>>> ??? 'prediction'. +>>> ???? > +>>> ???? >? ? ? ? ? However, I can't for the life of me see where this +>>> ??? dependence +>>> ???? >? ? ?could +>>> ???? >? ? ?come from. Neither the DESCRIPTION file of the last-archived +>>> ??? version on +>>> ???? >? ? ?CRAN +>>> ???? > +>>> ? >>, +>>> ???? >? ? ?nor the version on github +>>> ??? >> ??? +>>> ???? >? ? ?>> ??? >>, seem to +>>> ???? >? ? ?show any signs of importing prediction ... ?? I suppose +>>> there's a +>>> ???? >? ? ?possibility of a recursive dependence, but in that case why +>>> ??? wouldn't +>>> ???? >? ? ?the +>>> ???? >? ? ?direct dependence be reported? +>>> ???? > +>>> ???? >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +>>> ???? >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, +>>> performance, +>>> ???? >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +>>> ??? rlang, purrr +>>> ???? >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +>>> ???? > +>>> ???? >? ? ? ? ?What am I missing? +>>> ???? > +>>> ???? >? ? ? ? ?(I'm concerned because I have packages that Suggest: +>>> ??? dotwhisker, +>>> ???? >? ? ?and +>>> ???? >? ? ?the absence of the package from repos is breaking GitHub +>>> Actions +>>> ???? >? ? ?checks ...) +>>> ???? > +>>> ???? > +>>> ???? >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +>>> ???? >? ? ?repository: +>>> ???? > https://github.com/fsolt/dotwhisker/issues/115 +>>> ??? +>>> ???? >? ? ?>> ??? >) +>>> ???? > +>>> ???? >? ? ?______________________________________________ +>>> ???? > R-package-devel at r-project.org +>>> ??? +>>> ??? >> ??? > +>>> ???? >? ? ?mailing list +>>> ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>> ??? +>>> ???? >? ? ?>> ??? > +>>> ???? > +>>> +>>> ??? -- ??? Dr. Benjamin Bolker +>>> ??? Professor, Mathematics & Statistics and Biology, McMaster University +>>> ??? Director, School of Computational Science and Engineering +>>> ??? (Acting) Graduate chair, Mathematics & Statistics +>>> ???? ?> E-mail is sent at my convenience; I don't expect replies +>>> outside of +>>> ??? working hours. +>>> +>>> ??? ______________________________________________ +>>> ??? R-package-devel at r-project.org +>>> ??? mailing list +>>> ??? https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>> ??? +>>> +>> + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de Thu Apr 18 15:48:30 2024 +From: ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de (Uwe Ligges) +Date: Thu, 18 Apr 2024 15:48:30 +0200 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + + +Message-ID: <2bfafd04-5f4e-4c25-ab49-fbcbec6ef929@statistik.tu-dortmund.de> + + + +On 18.04.2024 15:43, Ben Bolker wrote: +> ?To clarify, from an off-list conversation: +> +> ? AFAICT the chain is +> +> ? dotwhisker Imports +> ???? margins, which Imports +> ?????? prediction, which Enhances +> ???????? ffbase? (archived in 2022 for 'coercion to logical' problems) +> +> ?(that conversation also pointed out that Enhances is a dependency *in +> the opposite direction* -- i.e. if A Enhances B, it's not entirely clear +> why the disappearance of B should matter at all ...) + +The year old check notes in prediciton matter, not the level of any +dependencies. + +Best, +Uwe Ligges + + + + +> +> +> +> On 2024-04-18 9:35 a.m., Ben Bolker wrote: +>> ??? Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +>> has apparently just caught up to checking.? What's a little +>> frustrating (to me) is that the dependence of prediction on ffbase is +>> *very* soft ("enhances") ... +>> +>> On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +>>> The cascade is even longer. prediction got archived because ffbase +>>> was no longer available. +>>> https://cran.r-project.org/web/packages/ffbase/ +>>> +>>> +>>> ir. Thierry Onkelinx +>>> Statisticus / Statistician +>>> +>>> Vlaamse Overheid / Government of Flanders +>>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR +>>> NATURE AND FOREST +>>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +>>> thierry.onkelinx at inbo.be +>>> Havenlaan 88 bus 73, 1000 Brussel +>>> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +>>> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +>>> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid +>>> haar dossiers volledig digitaal behandelen. Poststukken met de +>>> vermelding ?vertrouwelijk? worden niet ingescand, maar ongeopend aan +>>> de geadresseerde bezorgd./ +>>> www.inbo.be +>>> +>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>> To call in the statistician after the experiment is done may be no +>>> more than asking him to perform a post-mortem examination: he may be +>>> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +>>> The plural of anecdote is not data. ~ Roger Brinner +>>> The combination of some data and an aching desire for an answer does +>>> not ensure that a reasonable answer can be extracted from a given +>>> body of data. ~ John Tukey +>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>> +>>> +>>> +>>> +>>> Op do 18 apr 2024 om 15:25 schreef Ben Bolker >> >: +>>> +>>> ???? ? ?Thank you! (I know about package_dependencies() but ran into +>>> ??? precisely the same problem and didn't want to re-implement it ...) +>>> +>>> ??? On 2024-04-18 9:11 a.m., Josiah Parry wrote: +>>> ???? > Well, after trying to install the package, I believe the issue is +>>> ???? > because margins has been archived. +>>> ???? > +>>> ???? > https://cran.r-project.org/web/packages/margins/index.html +>>> ??? +>>> ???? > >> ??? > +>>> ???? > +>>> ???? > You can check recursive dependencies using +>>> ???? > `tools::package_dependencies("pkg", recursive = TRUE)` which +>>> ??? would help +>>> ???? > you in this case. I couldn't run it since the package is not +>>> ??? available +>>> ???? > on CRAN, however. +>>> ???? > +>>> ???? > +>>> ???? > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker >> ??? +>>> ???? > >> wrote: +>>> ???? > +>>> ???? >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +>>> ???? > https://cran.r-project.org/web/packages/dotwhisker/index.html +>>> ??? +>>> ???? > ?>> ??? > +>>> ???? > +>>> ???? >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN +>>> repository +>>> ???? >? ? ? ? ? ?... +>>> ???? > +>>> ???? >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +>>> ??? 'prediction'. +>>> ???? > +>>> ???? >? ? ? ? ? However, I can't for the life of me see where this +>>> ??? dependence +>>> ???? >? ? ?could +>>> ???? >? ? ?come from. Neither the DESCRIPTION file of the last-archived +>>> ??? version on +>>> ???? >? ? ?CRAN +>>> ???? > +>>> ? >>, +>>> ???? >? ? ?nor the version on github +>>> ??? >> ??? +>>> ???? >? ? ?>> ??? >>, seem to +>>> ???? >? ? ?show any signs of importing prediction ... ?? I suppose +>>> there's a +>>> ???? >? ? ?possibility of a recursive dependence, but in that case why +>>> ??? wouldn't +>>> ???? >? ? ?the +>>> ???? >? ? ?direct dependence be reported? +>>> ???? > +>>> ???? >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +>>> ???? >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, +>>> performance, +>>> ???? >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +>>> ??? rlang, purrr +>>> ???? >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +>>> ???? > +>>> ???? >? ? ? ? ?What am I missing? +>>> ???? > +>>> ???? >? ? ? ? ?(I'm concerned because I have packages that Suggest: +>>> ??? dotwhisker, +>>> ???? >? ? ?and +>>> ???? >? ? ?the absence of the package from repos is breaking GitHub +>>> Actions +>>> ???? >? ? ?checks ...) +>>> ???? > +>>> ???? > +>>> ???? >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +>>> ???? >? ? ?repository: +>>> ???? > https://github.com/fsolt/dotwhisker/issues/115 +>>> ??? +>>> ???? >? ? ?>> ??? >) +>>> ???? > +>>> ???? >? ? ?______________________________________________ +>>> ???? > R-package-devel at r-project.org +>>> ??? +>>> ??? >> ??? > +>>> ???? >? ? ?mailing list +>>> ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>> ??? +>>> ???? >? ? ?>> ??? > +>>> ???? > +>>> +>>> ??? -- ??? Dr. Benjamin Bolker +>>> ??? Professor, Mathematics & Statistics and Biology, McMaster University +>>> ??? Director, School of Computational Science and Engineering +>>> ??? (Acting) Graduate chair, Mathematics & Statistics +>>> ???? ?> E-mail is sent at my convenience; I don't expect replies +>>> outside of +>>> ??? working hours. +>>> +>>> ??? ______________________________________________ +>>> ??? R-package-devel at r-project.org +>>> ??? mailing list +>>> ??? https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>> ??? +>>> +>> +> + +From ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de Thu Apr 18 15:49:02 2024 +From: ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de (Uwe Ligges) +Date: Thu, 18 Apr 2024 15:49:02 +0200 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: <2bfafd04-5f4e-4c25-ab49-fbcbec6ef929@statistik.tu-dortmund.de> +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + + + <2bfafd04-5f4e-4c25-ab49-fbcbec6ef929@statistik.tu-dortmund.de> +Message-ID: + + + +On 18.04.2024 15:48, Uwe Ligges wrote: +> +> +> On 18.04.2024 15:43, Ben Bolker wrote: +>> ??To clarify, from an off-list conversation: +>> +>> ?? AFAICT the chain is +>> +>> ?? dotwhisker Imports +>> ????? margins, which Imports +>> ??????? prediction, which Enhances +>> ????????? ffbase? (archived in 2022 for 'coercion to logical' problems) +>> +>> ??(that conversation also pointed out that Enhances is a dependency +>> *in the opposite direction* -- i.e. if A Enhances B, it's not entirely +>> clear why the disappearance of B should matter at all ...) +> +> The year old check notes in prediciton matter, not the level of any +> dependencies. + +.. and even more the non-maintainance state of prediction. + +Best, +Uwe Ligges + + +> +> Best, +> Uwe Ligges +> +> +> +> +>> +>> +>> +>> On 2024-04-18 9:35 a.m., Ben Bolker wrote: +>>> ??? Yes, but ffbase was archived a long time ago (2022-04-04) and +>>> CRAN has apparently just caught up to checking.? What's a little +>>> frustrating (to me) is that the dependence of prediction on ffbase is +>>> *very* soft ("enhances") ... +>>> +>>> On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +>>>> The cascade is even longer. prediction got archived because ffbase +>>>> was no longer available. +>>>> https://cran.r-project.org/web/packages/ffbase/ +>>>> +>>>> +>>>> ir. Thierry Onkelinx +>>>> Statisticus / Statistician +>>>> +>>>> Vlaamse Overheid / Government of Flanders +>>>> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR +>>>> NATURE AND FOREST +>>>> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +>>>> thierry.onkelinx at inbo.be +>>>> Havenlaan 88 bus 73, 1000 Brussel +>>>> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +>>>> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +>>>> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid +>>>> haar dossiers volledig digitaal behandelen. Poststukken met de +>>>> vermelding ?vertrouwelijk? worden niet ingescand, maar ongeopend aan +>>>> de geadresseerde bezorgd./ +>>>> www.inbo.be +>>>> +>>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>>> To call in the statistician after the experiment is done may be no +>>>> more than asking him to perform a post-mortem examination: he may be +>>>> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +>>>> The plural of anecdote is not data. ~ Roger Brinner +>>>> The combination of some data and an aching desire for an answer does +>>>> not ensure that a reasonable answer can be extracted from a given +>>>> body of data. ~ John Tukey +>>>> /////////////////////////////////////////////////////////////////////////////////////////// +>>>> +>>>> +>>>> +>>>> +>>>> Op do 18 apr 2024 om 15:25 schreef Ben Bolker >>> >: +>>>> +>>>> ???? ? ?Thank you! (I know about package_dependencies() but ran into +>>>> ??? precisely the same problem and didn't want to re-implement it ...) +>>>> +>>>> ??? On 2024-04-18 9:11 a.m., Josiah Parry wrote: +>>>> ???? > Well, after trying to install the package, I believe the +>>>> issue is +>>>> ???? > because margins has been archived. +>>>> ???? > +>>>> ???? > https://cran.r-project.org/web/packages/margins/index.html +>>>> ??? +>>>> ???? > >>> ??? > +>>>> ???? > +>>>> ???? > You can check recursive dependencies using +>>>> ???? > `tools::package_dependencies("pkg", recursive = TRUE)` which +>>>> ??? would help +>>>> ???? > you in this case. I couldn't run it since the package is not +>>>> ??? available +>>>> ???? > on CRAN, however. +>>>> ???? > +>>>> ???? > +>>>> ???? > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker >>> ??? +>>>> ???? > >> wrote: +>>>> ???? > +>>>> ???? >? ? ? ? ?The 'dotwhisker' package was archived on CRAN: from +>>>> ???? > https://cran.r-project.org/web/packages/dotwhisker/index.html +>>>> ??? +>>>> ???? > ?>>> ??? > +>>>> ???? > +>>>> ???? >? ? ? ? ? ?Package ?dotwhisker? was removed from the CRAN +>>>> repository +>>>> ???? >? ? ? ? ? ?... +>>>> ???? > +>>>> ???? >? ? ? ? ? ?Archived on 2024-04-12 as requires archived package +>>>> ??? 'prediction'. +>>>> ???? > +>>>> ???? >? ? ? ? ? However, I can't for the life of me see where this +>>>> ??? dependence +>>>> ???? >? ? ?could +>>>> ???? >? ? ?come from. Neither the DESCRIPTION file of the last-archived +>>>> ??? version on +>>>> ???? >? ? ?CRAN +>>>> ???? > +>>>> ? >>, +>>>> ???? >? ? ?nor the version on github +>>>> ??? >>> ??? +>>>> ???? >? ? ?>>> ??? >>, seem to +>>>> ???? >? ? ?show any signs of importing prediction ... ?? I suppose +>>>> there's a +>>>> ???? >? ? ?possibility of a recursive dependence, but in that case why +>>>> ??? wouldn't +>>>> ???? >? ? ?the +>>>> ???? >? ? ?direct dependence be reported? +>>>> ???? > +>>>> ???? >? ? ?Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +>>>> ???? >? ? ?Imports: grid, gtable, gridExtra, stats, parameters, +>>>> performance, +>>>> ???? >? ? ? ? ? ? ? ?patchwork, margins, dplyr, stringr, ggstance, +>>>> ??? rlang, purrr +>>>> ???? >? ? ?Suggests: ordinal, tibble, knitr, rmarkdown, broom +>>>> ???? > +>>>> ???? >? ? ? ? ?What am I missing? +>>>> ???? > +>>>> ???? >? ? ? ? ?(I'm concerned because I have packages that Suggest: +>>>> ??? dotwhisker, +>>>> ???? >? ? ?and +>>>> ???? >? ? ?the absence of the package from repos is breaking GitHub +>>>> Actions +>>>> ???? >? ? ?checks ...) +>>>> ???? > +>>>> ???? > +>>>> ???? >? ? ? ? ?(This is cross-posted from an issue on the dotwhisker GH +>>>> ???? >? ? ?repository: +>>>> ???? > https://github.com/fsolt/dotwhisker/issues/115 +>>>> ??? +>>>> ???? >? ? ?>>> ??? >) +>>>> ???? > +>>>> ???? >? ? ?______________________________________________ +>>>> ???? > R-package-devel at r-project.org +>>>> ??? +>>>> ??? >>> ??? > +>>>> ???? >? ? ?mailing list +>>>> ???? > https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>>> ??? +>>>> ???? >? ? ?>>> ??? > +>>>> ???? > +>>>> +>>>> ??? -- ??? Dr. Benjamin Bolker +>>>> ??? Professor, Mathematics & Statistics and Biology, McMaster +>>>> University +>>>> ??? Director, School of Computational Science and Engineering +>>>> ??? (Acting) Graduate chair, Mathematics & Statistics +>>>> ???? ?> E-mail is sent at my convenience; I don't expect replies +>>>> outside of +>>>> ??? working hours. +>>>> +>>>> ??? ______________________________________________ +>>>> ??? R-package-devel at r-project.org +>>>> +>>>> ??? mailing list +>>>> ??? https://stat.ethz.ch/mailman/listinfo/r-package-devel +>>>> ??? +>>>> +>>> +>> + +From henr|k@bengt@@on @end|ng |rom gm@||@com Thu Apr 18 18:51:06 2024 +From: henr|k@bengt@@on @end|ng |rom gm@||@com (Henrik Bengtsson) +Date: Thu, 18 Apr 2024 09:51:06 -0700 +Subject: [R-pkg-devel] puzzling removal of 'dotwhisker' from CRAN +In-Reply-To: +References: <8d9ab8de-476e-4e9e-92ab-9120f21b06f1@gmail.com> + + + + + +Message-ID: + +On Thu, Apr 18, 2024 at 6:41?AM Uwe Ligges + wrote: +> +> On 18.04.2024 15:35, Ben Bolker wrote: +> > Yes, but ffbase was archived a long time ago (2022-04-04) and CRAN +> > has apparently just caught up to checking. What's a little frustrating +> > (to me) is that the dependence of prediction on ffbase is *very* soft +> > ("enhances") ... +> +> No, but CRAN has still not received an update and asked for this each +> month this year, so in Jan, Feb, and March without a response, so we +> assume prediction is unmaintained. Also, this was escalated to reverse +> depends. + +Uwe, has the CRAN Team ever considered making these request-for-update +email messages from CRAN public in real-time? For instance, there +could be a public "read-only" mailing list that anyone can subscribe +to, but not send/reply to. I see several advantages with such an +approach, e.g. + +* maintainers of reverse dependencies would be aware of potential +problems much sooner, +* so would end-users who rely on the package (who often only notice +when a package is archived), +* the community could early on offer their help to the package maintainer, and +* the community could help locate and notify maintainers whose email +addresses are no longer working. + +I'd imagine this would help lower the workload on the CRAN Team, so a +win-win for everyone. I, for sure, would find that useful. + +Thanks, + +Henrik + +>> Best, +> Uwe Ligges +> +> +> > +> > On 2024-04-18 9:28 a.m., Thierry Onkelinx wrote: +> >> The cascade is even longer. prediction got archived because ffbase was +> >> no longer available. https://cran.r-project.org/web/packages/ffbase/ +> >> +> >> +> >> ir. Thierry Onkelinx +> >> Statisticus / Statistician +> >> +> >> Vlaamse Overheid / Government of Flanders +> >> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE +> >> AND FOREST +> >> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance +> >> thierry.onkelinx at inbo.be +> >> Havenlaan 88 bus 73, 1000 Brussel +> >> *Postadres:* Koning Albert II-laan 15 bus 186, 1210 Brussel +> >> /Poststukken die naar dit adres worden gestuurd, worden ingescand en +> >> digitaal aan de geadresseerde bezorgd. Zo kan de Vlaamse overheid haar +> >> dossiers volledig digitaal behandelen. Poststukken met de vermelding +> >> ?vertrouwelijk? worden niet ingescand, maar ongeopend aan de +> >> geadresseerde bezorgd./ +> >> www.inbo.be +> >> +> >> /////////////////////////////////////////////////////////////////////////////////////////// +> >> To call in the statistician after the experiment is done may be no +> >> more than asking him to perform a post-mortem examination: he may be +> >> able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher +> >> The plural of anecdote is not data. ~ Roger Brinner +> >> The combination of some data and an aching desire for an answer does +> >> not ensure that a reasonable answer can be extracted from a given body +> >> of data. ~ John Tukey +> >> /////////////////////////////////////////////////////////////////////////////////////////// +> >> +> >> +> >> +> >> +> >> Op do 18 apr 2024 om 15:25 schreef Ben Bolker >> >: +> >> +> >> Thank you! (I know about package_dependencies() but ran into +> >> precisely the same problem and didn't want to re-implement it ...) +> >> +> >> On 2024-04-18 9:11 a.m., Josiah Parry wrote: +> >> > Well, after trying to install the package, I believe the issue is +> >> > because margins has been archived. +> >> > +> >> > https://cran.r-project.org/web/packages/margins/index.html +> >> +> >> > >> > +> >> > +> >> > You can check recursive dependencies using +> >> > `tools::package_dependencies("pkg", recursive = TRUE)` which +> >> would help +> >> > you in this case. I couldn't run it since the package is not +> >> available +> >> > on CRAN, however. +> >> > +> >> > +> >> > On Thu, Apr 18, 2024 at 9:05?AM Ben Bolker >> +> >> > >> wrote: +> >> > +> >> > The 'dotwhisker' package was archived on CRAN: from +> >> > https://cran.r-project.org/web/packages/dotwhisker/index.html +> >> +> >> > +> >> >> > +> >> > +> >> > Package ?dotwhisker? was removed from the CRAN +> >> repository +> >> > ... +> >> > +> >> > Archived on 2024-04-12 as requires archived package +> >> 'prediction'. +> >> > +> >> > However, I can't for the life of me see where this +> >> dependence +> >> > could +> >> > come from. Neither the DESCRIPTION file of the last-archived +> >> version on +> >> > CRAN +> >> > +> >> >>, +> >> > nor the version on github +> >> >> +> >> > >> >>, seem to +> >> > show any signs of importing prediction ... ?? I suppose +> >> there's a +> >> > possibility of a recursive dependence, but in that case why +> >> wouldn't +> >> > the +> >> > direct dependence be reported? +> >> > +> >> > Depends: R (>= 3.2.0), ggplot2 (>= 2.2.1), +> >> > Imports: grid, gtable, gridExtra, stats, parameters, +> >> performance, +> >> > patchwork, margins, dplyr, stringr, ggstance, +> >> rlang, purrr +> >> > Suggests: ordinal, tibble, knitr, rmarkdown, broom +> >> > +> >> > What am I missing? +> >> > +> >> > (I'm concerned because I have packages that Suggest: +> >> dotwhisker, +> >> > and +> >> > the absence of the package from repos is breaking GitHub +> >> Actions +> >> > checks ...) +> >> > +> >> > +> >> > (This is cross-posted from an issue on the dotwhisker GH +> >> > repository: +> >> > https://github.com/fsolt/dotwhisker/issues/115 +> >> +> >> > >> >) +> >> > +> >> > ______________________________________________ +> >> > R-package-devel at r-project.org +> >> +> >> >> > +> >> > mailing list +> >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel +> >> +> >> > >> > +> >> > +> >> +> >> -- Dr. Benjamin Bolker +> >> Professor, Mathematics & Statistics and Biology, McMaster University +> >> Director, School of Computational Science and Engineering +> >> (Acting) Graduate chair, Mathematics & Statistics +> >> > E-mail is sent at my convenience; I don't expect replies +> >> outside of +> >> working hours. +> >> +> >> ______________________________________________ +> >> R-package-devel at r-project.org +> >> mailing list +> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> >> +> >> +> > +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From |@@@c-t-peter@en @end|ng |rom u|ow@@edu Mon Apr 22 19:00:27 2024 +From: |@@@c-t-peter@en @end|ng |rom u|ow@@edu (Petersen, Isaac T) +Date: Mon, 22 Apr 2024 17:00:27 +0000 +Subject: [R-pkg-devel] Package submission to CRAN not passing incoming checks +Message-ID: + +Dear R-package-devel, + +This my first post--I read the posting guidelines, but my apologies in advance if I make a mistake. + +I am trying to post my R package to CRAN. I just submitted it to CRAN but received a note that the package "does not pass the incoming checks automatically". + +Here are the results from win-builder: https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/ + +As far as I can tell, there are 3 notes to address. However, I'm not sure how to address them. + +1) The first note appears to be "Version contains large components", which includes the contents of the LICENSE file (CC BY 4.0). I'm not sure if this is a problem that needs to be addressed (or how to address it). + +2) The second note says: + +"Found the following (possibly) invalid file URIs: + URI: 10.1177/0146621613475471 + From: man/itemInformation.Rd + URI: 10.1177/0146621613475471 + From: man/standardErrorIRT.Rd" + +However, I verified that those DOIs resolve correctly, so I'm not sure how to address this note. + +3) The third note (in the Debian but not Windows version) says: + +"* checking for non-standard things in the check directory ... NOTE +Found the following files/directories: + ?encryptionKey.RData? ?encrypytedCredentials.txt?" + +These files are generated in the examples for one of the functions to demonstrate how to read data using an encryption key: https://github.com/DevPsyLab/petersenlab/blob/9ece9d7dc32727c1315a03bc2810cc9c957971d1/R/readEncryptedData.R#L24. I'm not sure if this is a problem that needs to be addressed (or how to address it). + +The source code for my R package (petersenlab) is here: https://github.com/DevPsyLab/petersenlab + +Thanks very much in advance, +Isaac + + [[alternative HTML version deleted]] + + +From k@@perd@n|e|h@n@en @end|ng |rom gm@||@com Tue Apr 23 04:09:04 2024 +From: k@@perd@n|e|h@n@en @end|ng |rom gm@||@com (Kasper Daniel Hansen) +Date: Mon, 22 Apr 2024 22:09:04 -0400 +Subject: [R-pkg-devel] Package submission to CRAN not passing incoming + checks +In-Reply-To: +References: +Message-ID: + +1. The version number complaint is the use of 0.1.2-9033. It is complaining +about 9033. Personally, I would not use the -XXXX style, but that is a +personal choice I guess. R-exts says + "The mandatory ?Version? field gives the version of the package. This is +a sequence of at least *two* (and usually three) non-negative integers +separated by single ?.? or ?-? characters. The canonical form is as shown +in the example, and a version such as ?0.01? or ?0.01.0? will be handled as +if it were ?0.1-0?. It is *not* a decimal number, so for example 0.9 < 0.75 +since 9 < 75." +2. Those are not URLs, they are DOIs. The Rd format has a \doi{} command +you should use +3. If your examples generate files, I would use the tempfile() command from +base R. + +On Mon, Apr 22, 2024 at 8:25?PM Petersen, Isaac T < +isaac-t-petersen at uiowa.edu> wrote: + +> Dear R-package-devel, +> +> This my first post--I read the posting guidelines, but my apologies in +> advance if I make a mistake. +> +> I am trying to post my R package to CRAN. I just submitted it to CRAN but +> received a note that the package "does not pass the incoming checks +> automatically". +> +> Here are the results from win-builder: +> https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/ +> +> As far as I can tell, there are 3 notes to address. However, I'm not sure +> how to address them. +> +> 1) The first note appears to be "Version contains large components", which +> includes the contents of the LICENSE file (CC BY 4.0). I'm not sure if this +> is a problem that needs to be addressed (or how to address it). +> +> 2) The second note says: +> +> "Found the following (possibly) invalid file URIs: +> URI: 10.1177/0146621613475471 +> From: man/itemInformation.Rd +> URI: 10.1177/0146621613475471 +> From: man/standardErrorIRT.Rd" +> +> However, I verified that those DOIs resolve correctly, so I'm not sure how +> to address this note. +> +> 3) The third note (in the Debian but not Windows version) says: +> +> "* checking for non-standard things in the check directory ... NOTE +> Found the following files/directories: +> ?encryptionKey.RData? ?encrypytedCredentials.txt?" +> +> These files are generated in the examples for one of the functions to +> demonstrate how to read data using an encryption key: +> https://github.com/DevPsyLab/petersenlab/blob/9ece9d7dc32727c1315a03bc2810cc9c957971d1/R/readEncryptedData.R#L24. +> I'm not sure if this is a problem that needs to be addressed (or how to +> address it). +> +> The source code for my R package (petersenlab) is here: +> https://github.com/DevPsyLab/petersenlab +> +> Thanks very much in advance, +> Isaac +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +-- +Best, +Kasper + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Tue Apr 23 08:46:04 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Tue, 23 Apr 2024 09:46:04 +0300 +Subject: [R-pkg-devel] Package submission to CRAN not passing incoming + checks +In-Reply-To: +References: +Message-ID: <20240423094604.1da0617e@Tarkus> + +Dear Isaac, + +? Mon, 22 Apr 2024 17:00:27 +0000 +"Petersen, Isaac T" ?????: + +> This my first post--I read the posting guidelines, but my apologies +> in advance if I make a mistake. + +Welcome to R-package-devel! You're doing just fine. + +> 1) The first note <...> includes the contents of the LICENSE file + +It's multiple NOTEs in a trench coat. Kasper has addressed the "large +version components" and the DOIs interpreted as file URIs, but there's +one more. + +The ' + file LICENSE' syntax has two uses: (1) +for when the terms of the license is a template, requiring the author +of the software to substitute some information (e.g. the year and the +copyright holder for MIT) and (2) for when a package puts additional +restrictions on the base license. + +(Hmm. Only case (2) is currently described at +; case +(1) is only described inside the license files.) + +The CRAN team has expressed a preference for the package authors not to +put 20000 twisty little copies of standard licenses, all slightly +different, inside their packages. Since you're not restricting CC BY +4.0, it's enough to say 'License: CC BY 4.0'. If you'd like a full copy +of the license text in your source code repository, that's fine, but +you'll need to list the file in .Rbuildignore: +https://cran.r-project.org/doc/manuals/R-exts.html#Building-package-tarballs + +Speaking of the Creative Commons license: the choice of a license for +your code is obviously yours, but Creative Commons themselves recommend +against using their licenses for software: +. +I can't recommend you a license - that would be politically motivated +meddling in foreign affairs - but the lists linked by the CC FAQ and +Writing R Extensions section 1.1.2 should provide a good starting point. + +> Here are the results from win-builder: +> https://win-builder.r-project.org/incoming_pretest/petersenlab_0.1.2-9033_20240415_212322/ + +There is one more NOTE: + +>> * checking examples ... [437s/438s] NOTE +>> Examples with CPU (user + system) or elapsed time > 5s +>> user system elapsed +>> load_or_install 349.410 37.410 387.233 +>> vwReg 35.199 0.379 35.606 + +The examples are not only for the user to read in the help page; they +are also for the user to run example(vwReg) and see your code in action +(and for R CMD check to see whether they crash, including regularly on +CRAN). + +For vwReg, try reducing the number of regressions you are running +(since your dataset is mtcars, which is already very compact). + +For load_or_install, we have the additional issue that running +example(load_or_install) modifies the contents of the R library and the +search path, which belong to the user. The CRAN policy forbids such +modifications: + +Examples in general should change as little of the global state of the +R session and the underlying computer as possible. I suggest wrapping +the example in \dontrun{} (since everything about load_or_install() is +about altering global state) and creating a test for the function in +tests/*.R. + +The test should set up a new library under tempdir(), run +load_or_install(), check the outcomes (that the desired package is +attached, etc.) and clean up after itself. There's also the matter of +the package not failing without a connection to the Internet, which is +another CRAN policy requirement. You might have to bring a very small +test package in inst/extdata just for load_or_install() to install and +load it, so that R CMD check won't fail when running offline. + +-- +Best regards, +Ivan + + +From |@@@c-t-peter@en @end|ng |rom u|ow@@edu Wed Apr 24 02:17:28 2024 +From: |@@@c-t-peter@en @end|ng |rom u|ow@@edu (Petersen, Isaac T) +Date: Wed, 24 Apr 2024 00:17:28 +0000 +Subject: [R-pkg-devel] + [External] Re: Package submission to CRAN not passing + incoming checks +In-Reply-To: <20240423094604.1da0617e@Tarkus> +References: + <20240423094604.1da0617e@Tarkus> +Message-ID: + +Dear Ivan and Kasper, + + + +Thanks very much for the helpful guidance. I made the changes you described, including changing the version number (to 1.0.0), changing the URL codes to DOI codes, using the tempfile() command when generating files, changing the license to MIT (and excluding the license file in the .Rbuildignore file), and enclosing some examples with \dontrun{}. + + + +Following Ivan?s suggestion, I created a test file to verify that the load_or_install() function works as expected, and included two small test packages to verify that the function can install and load them without needing access to the internet. However, I receive an error when running the test locally (the error is enclosed below this email). The error suggests to me that the test cannot load the packages with library() after installing them. + + + +My test file is here: + +https://github.com/DevPsyLab/petersenlab/blob/main/tests/testthat/test_load_or_install.R + + + +I included the packages (including the raw package folders and their .tar.gz files) in the /inst/extdata folder. + + + +Any help would be greatly appreciated. + + + +Many thanks, + +Isaac + + + +?? Test failures ??????????????????????????????????????????????????????? testthat ???? + + + +> # This file is part of the standard setup for testthat. + +> # It is recommended that you do not modify it. + +> # + +> # Where should you do additional test configuration? + +> # Learn more about the roles of various files in: + +> # * https://r-pkgs.org/testing-design.html#sec-tests-files-overview + +> # * https://testthat.r-lib.org/articles/special-files.html + +> + +> library(testthat) + +Warning message: + +package 'testthat' was built under R version 4.3.3 + +> library(petersenlab) + +> + +> test_check("petersenlab") + +Installing package into 'C:/Users/itpetersen/AppData/Local/Temp/RtmpCEqqMl/working_dir/Rtmp0uuccD' + +(as 'lib' is unspecified) + +Warning: invalid package 'testpackage1' + +Error: ERROR: no packages specified + +[ FAIL 2 | WARN 1 | SKIP 0 | PASS 0 ] + + + +?? Warnings ???????????????????????????????????????????????????????????????????? + +?? Warning ('test_load_or_install.R:19:3'): load_or_install installs and loads packages correctly ?? + +installation of package 'testpackage1' had non-zero exit status + +Backtrace: + + ? + + 1. ??petersenlab::load_or_install(...) at test_load_or_install.R:19:3 + + 2. ??utils::install.packages(package_name, ...) + + + +?? Failed tests ???????????????????????????????????????????????????????????????? + +?? Error ('test_load_or_install.R:19:3'): load_or_install installs and loads packages correctly ?? + + + +Error in `library(package_name, character.only = TRUE, quietly = TRUE, + + verbose = FALSE)`: there is no package called 'testpackage1' + +Backtrace: + + ? + + 1. ??petersenlab::load_or_install(...) at test_load_or_install.R:19:3 + + 2. ??base::library(...) + +?? Error ('test_load_or_install.R:4:1'): (code run outside of `test_that()`) ??? + + + +Error in `loadNamespace(x)`: there is no package called 'waldo' + +Backtrace: + + ? + + 1. ??testthat::test_check("petersenlab") + + 2. ? ??testthat::test_dir(...) + + 3. ? ??testthat:::test_files(...) + + 4. ? ??testthat:::test_files_serial(...) + + 5. ? ??testthat::with_reporter(...) + + 6. ? ? ??base::tryCatch(...) + + 7. ? ? ??base (local) tryCatchList(expr, classes, parentenv, handlers) + + 8. ? ? ??base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]]) + + 9. ? ? ??base (local) doTryCatch(return(expr), name, parentenv, handler) + + 10. ? ??base::lapply(...) + + 11. ? ??testthat (local) FUN(X[[i]], ...) + + 12. ? ??testthat::source_file(path, env = env(env), desc = desc, error_call = error_call) + + 13. ? ??testthat:::test_code(test = NULL, code = exprs, env = env, default_reporter = StopReporter$new()) + + 14. ? ??base::tryCatch(...) + + 15. ? ? ??base (local) tryCatchList(expr, classes, parentenv, handlers) + + 16. ? ? ??base (local) tryCatchOne(...) + + 17. ? ? ? ??base (local) doTryCatch(return(expr), name, parentenv, handler) + + 18. ? ? ??base (local) tryCatchList(expr, names[-nh], parentenv, handlers[-nh]) + + 19. ? ? ??base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]]) + + 20. ? ? ??base (local) doTryCatch(return(expr), name, parentenv, handler) + + 21. ? ??base::withCallingHandlers(...) + + 22. ? ??base::eval(code, test_env) + + 23. ? ??base::eval(code, test_env) + + 24. ? ??testthat::test_that(...) at test_load_or_install.R:4:1 + + 25. ? ??testthat:::test_code(desc, code, env = parent.frame(), default_reporter = local_interactive_reporter()) + + 26. ? ??testthat:::testthat_state_condition(before, after, call = sys.call(-1)) + + 27. ? ??testthat:::waldo_compare(before, after, x_arg = "before", y_arg = "after") + + 28. ??base::loadNamespace(x) + + 29. ??base::withRestarts(stop(cond), retry_loadNamespace = function() NULL) + + 30. ??base (local) withOneRestart(expr, restarts[[1L]]) + + 31. ??base (local) doWithOneRestart(return(expr), restart) + + + +[ FAIL 2 | WARN 1 | SKIP 0 | PASS 0 ] + +Error: Test failures + +Execution halted + + + +1 error ? | 0 warnings ? | 1 note ? + +Error: R CMD check found ERRORs + +Execution halted + + + +Exited with status 1. + +________________________________ +From: Ivan Krylov +Sent: Tuesday, April 23, 2024 1:46 AM +To: Petersen, Isaac T +Cc: r-package-devel at r-project.org +Subject: [External] Re: [R-pkg-devel] Package submission to CRAN not passing incoming checks + +[You don't often get email from ikrylov at disroot.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] + +Dear Isaac, + +? Mon, 22 Apr 2024 17:00:27 +0000 +"Petersen, Isaac T" ?????: + +> This my first post--I read the posting guidelines, but my apologies +> in advance if I make a mistake. + +Welcome to R-package-devel! You're doing just fine. + +> 1) The first note <...> includes the contents of the LICENSE file + +It's multiple NOTEs in a trench coat. Kasper has addressed the "large +version components" and the DOIs interpreted as file URIs, but there's +one more. + +The ' + file LICENSE' syntax has two uses: (1) +for when the terms of the license is a template, requiring the author +of the software to substitute some information (e.g. the year and the +copyright holder for MIT) and (2) for when a package puts additional +restrictions on the base license. + +(Hmm. Only case (2) is currently described at +>; case +(1) is only described inside the license files.) + +The CRAN team has expressed a preference for the package authors not to +put 20000 twisty little copies of standard licenses, all slightly +different, inside their packages. Since you're not restricting CC BY +4.0, it's enough to say 'License: CC BY 4.0'. If you'd like a full copy +of the license text in your source code repository, that's fine, but +you'll need to list the file in .Rbuildignore: +https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcran.r-project.org%2Fdoc%2Fmanuals%2FR-exts.html%23Building-package-tarballs&data=05%7C02%7Cisaac-t-petersen%40uiowa.edu%7C3a0f2254132f4cd6205608dc63610e82%7C1bc445959aba4fc3b8ec7b94a5586fdc%7C1%7C1%7C638494515735420011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=kslE9klwZD%2BvBHX3I%2FkBewpNLnr14cgnxOc%2FQIZBLR0%3D&reserved=0 + +Speaking of the Creative Commons license: the choice of a license for +your code is obviously yours, but Creative Commons themselves recommend +against using their licenses for software: +>. +I can't recommend you a license - that would be politically motivated +meddling in foreign affairs - but the lists linked by the CC FAQ and +Writing R Extensions section 1.1.2 should provide a good starting point. + +> Here are the results from win-builder: +> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwin-builder.r-project.org%2Fincoming_pretest%2Fpetersenlab_0.1.2-9033_20240415_212322%2F&data=05%7C02%7Cisaac-t-petersen%40uiowa.edu%7C3a0f2254132f4cd6205608dc63610e82%7C1bc445959aba4fc3b8ec7b94a5586fdc%7C1%7C1%7C638494515735430793%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C40000%7C%7C%7C&sdata=S%2F18W%2Bh15GDI5dQRlBlvqhPVoEeP67MAwSIAsnIw4yw%3D&reserved=0 + +There is one more NOTE: + +>> * checking examples ... [437s/438s] NOTE +>> Examples with CPU (user + system) or elapsed time > 5s +>> user system elapsed +>> load_or_install 349.410 37.410 387.233 +>> vwReg 35.199 0.379 35.606 + +The examples are not only for the user to read in the help page; they +are also for the user to run example(vwReg) and see your code in action +(and for R CMD check to see whether they crash, including regularly on +CRAN). + +For vwReg, try reducing the number of regressions you are running +(since your dataset is mtcars, which is already very compact). + +For load_or_install, we have the additional issue that running +example(load_or_install) modifies the contents of the R library and the +search path, which belong to the user. The CRAN policy forbids such +modifications: > + +Examples in general should change as little of the global state of the +R session and the underlying computer as possible. I suggest wrapping +the example in \dontrun{} (since everything about load_or_install() is +about altering global state) and creating a test for the function in +tests/*.R. + +The test should set up a new library under tempdir(), run +load_or_install(), check the outcomes (that the desired package is +attached, etc.) and clean up after itself. There's also the matter of +the package not failing without a connection to the Internet, which is +another CRAN policy requirement. You might have to bring a very small +test package in inst/extdata just for load_or_install() to install and +load it, so that R CMD check won't fail when running offline. + +-- +Best regards, +Ivan + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Wed Apr 24 10:29:57 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 24 Apr 2024 11:29:57 +0300 +Subject: [R-pkg-devel] + [External] Re: Package submission to CRAN not passing + incoming checks +In-Reply-To: +References: + <20240423094604.1da0617e@Tarkus> + +Message-ID: <20240424112957.1669adb2@Tarkus> + +? Wed, 24 Apr 2024 00:17:28 +0000 +"Petersen, Isaac T" ?????: + +> I included the packages (including the raw package folders and their +> .tar.gz files) in the /inst/extdata folder. + +Would you prefer your test to install them from the source directories +(as you currently do, in which case the *.tar.gz files can be omitted) +or the *.tar.gz files (in which case you can set the `repos` argument +to a file:/// URI and omit the package directories and the setwd() +calls)? + +I think (but haven't tested) that the two problems that are currently +breaking your test are with .libPaths() and setwd(). + +.libPaths(temp_lib) overwrites the library paths with `temp_lib` and +the system libraries, the ones in %PROGRAMFILES%\R\R-*\library. In +particular, this removes %LOCALAPPDATA%\R\win-library\* from the list +of library paths, so the packages installed by the user (including +'waldo', which is needed by 'testthat') stop being available. + +In order to add temp_lib to the list of the paths, use +.libPaths(c(temp_lib, .libPaths())). + +Since setwd() returns the previous directory, one that was current +before setwd() was called, the code newpath <- setwd(filepath); +setwd(newpath) will keep the current directory, not set it to +`filepath`. Use oldpath <- setwd(filepath) instead. + +Since you're already using 'testthat' and it already depends on +'withr', you may find it easier to use withr::local_dir(...) and +withr::local_temp_libpaths(...). + +In order to test for a package being attached by load_or_install() (and +not just installed and loadable), check for 'package:testpackage1' +being present in the return value of search(). (This check is good +enough and much easier to write than comparing environments on the +search path with the package exports or comparing searchpaths() with +the paths under the temporary library.) + +Finally, I think that there is no need for the test_load_or_install() +call because I don't see the function being defined anywhere. Doesn't +test_that(...) run the tests by itself? + +-- +Best regards, +Ivan + + +From h@n@on @end|ng |rom dep@uw@edu Thu Apr 25 17:54:41 2024 +From: h@n@on @end|ng |rom dep@uw@edu (Bryan Hanson) +Date: Thu, 25 Apr 2024 08:54:41 -0700 +Subject: [R-pkg-devel] Some, but not all vignettes compressed +Message-ID: + +I have a peculiar problem regarding vignette compaction. Package LearnPCA has 8 vignettes. I am working on the devel branch with code at https://github.com/bryanhanson/LearnPCA/tree/devel. + +The problem is that at CRAN and on win-builder they detect that 5/8 vignettes need to be compacted. Locally however, 2/8 vignettes, not overlapping with the 5/8 identified at CRAN, are compacted during build. When I try to compact manually, compactPDF() reports it is not necesssary. + +I have looked at a related question by Ben Bolker (https://stat.ethz.ch/pipermail/r-package-devel/2020q4/006086.html) but that doesn't seem resolved. I am already taking the steps listed in this question: https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009831.html as well as several others. + +Regarding versions, I get + +gs --version +10.03.0 + +qpdf --version +qpdf version 11.9.0 + +Which seem to be the latest. Note these were installed with HomeBrew but I think R ships with at its own version of qpdf: + +Sys.which(Sys.getenv("R_QPDF", "qpdf")) + /Library/Frameworks/R.framework/Resources/bin/qpdf +"/Library/Frameworks/R.framework/Resources/bin/qpdf" + +I did not try the HomeBrew versions until I ran into trouble. + +Here are the steps I am taking. I am on MacOS 14.4.1, an M1 chip. + +1. Build via a makefile, with this command: + +R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME) + +The build process reports: + +* creating vignettes ... OK +* compacting vignettes and other PDF files + compacted ?Vig_01_Start_Here.pdf? from 244Kb to 44Kb + compacted ?Vig_08_Notes.pdf? from 239Kb to 38Kb + +Fine so far. + +I also tried to force the path to gs: + +export R_GSCMD="/opt/homebrew/bin/gs"; \ +export GS_QUALITY="ebook"; \ +R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME) + +With the same result. I did this because it seems R doesn't see my installation of GhostScript. + +And I tried to force a path to both compacting services: + +export R_GSCMD="/opt/homebrew/bin/gs"; \ +export GS_QUALITY="ebook"; \ +export R_QPDF="/opt/homebrew/bin/qpdf"; \ +R --no-init-file CMD build --resave-data --compact-vignettes=both $(PKG_NAME) + +With the same results. + +2. Submit to win-builder (same result seen on actual CRAN submission). The (partial) report is: + +* checking sizes of PDF files under 'inst/doc' ... WARNING + 'gs+qpdf' made some significant size reductions: + compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb + compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb + compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb + compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb + compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb + consider running tools::compactPDF(gs_quality = "ebook") on these files, + or build the source package with --compact-vignettes=both + +Note that these are *different* vignettes than those compacted during build, so build seems to have missed some (?). + +3. If I expand the tarball locally, point to the inst directory, and run + +tools::compactPDF("doc", gs_quality = "ebook", gs_cmd = "/opt/homebrew/bin/gs", verbose = TRUE) + +I get this: + +qs_quality="ebook" : use_gs=TRUE, use_qpdf=TRUE +#{pdf}s = length(paths) = 8 +- doc/Vig_01_Start_Here.pdf: gs: res=0; + qpdf: res=0; + ==> (new=49942)/(old=45101) = 1.10734 .. not worth using +- doc/Vig_02_Conceptual_Intro_PCA.pdf: gs: res=0; + qpdf: res=0; + ==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using +- doc/Vig_03_Step_By_Step_PCA.pdf: gs: res=0; + qpdf: res=0; + ==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using +- doc/Vig_04_Scores_Loadings.pdf: gs: res=0; + qpdf: res=0; + ==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using +- doc/Vig_05_Visualizing_PCA_3D.pdf: gs: res=0; + qpdf: res=0; + ==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using +- doc/Vig_06_Math_Behind_PCA.pdf: gs: res=0; + qpdf: res=0; + ==> (new=816690)/(old=571493) = 1.42905 .. not worth using +- doc/Vig_07_Functions_PCA.pdf: gs: res=0; + qpdf: res=0; + ==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using +- doc/Vig_08_Notes.pdf: gs: res=0; + qpdf: res=0; + ==> (new=40919)/(old=38953) = 1.05047 .. not worth using + +Any suggestions as to what is going on here and how to fix it? + +sessionInfo(): + +R version 4.4.0 RC (2024-04-16 r86468) +Platform: aarch64-apple-darwin20 +Running under: macOS Sonoma 14.4.1 + +Matrix products: default +BLAS: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRblas.0.dylib +LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.12.0 + +locale: +[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 + +time zone: America/Phoenix +tzcode source: internal + +attached base packages: +[1] stats graphics grDevices utils datasets methods base + +loaded via a namespace (and not attached): + [1] foghorn_1.5.2 utf8_1.2.4 R6_2.5.1 rvest_1.0.4 magrittr_2.0.3 + [6] rappdirs_0.3.3 glue_1.7.0 stringr_1.5.1 tibble_3.2.1 clisymbols_1.2.0 +[11] pkgconfig_2.0.3 lifecycle_1.0.4 xml2_1.3.6 cli_3.6.2 fansi_1.0.6 +[16] vctrs_0.6.5 compiler_4.4.0 httr_1.4.7 tools_4.4.0 curl_5.2.1 +[21] pillar_1.9.0 httr2_1.0.1 rlang_1.1.3 crayon_1.5.2 stringi_1.8.3 +[26] selectr_0.4-2 + + +============= +Bryan A. Hanson +Prof. Emeritus, DePauw University +Chemistry & Biochemistry +hanson at depauw.edu +profbryanhanson at gmail.com +Nerdy blog: ChemoSpec.org +I?m at GMT -7 year round + + + + + + + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Thu Apr 25 20:26:40 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 25 Apr 2024 21:26:40 +0300 +Subject: [R-pkg-devel] Some, but not all vignettes compressed +In-Reply-To: +References: +Message-ID: <20240425212640.39a2f275@Tarkus> + +? Thu, 25 Apr 2024 08:54:41 -0700 +Bryan Hanson ?????: + +> 'gs+qpdf' made some significant size reductions: +> compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb +> compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb +> compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb +> compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb +> compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb + +I'm getting similar (but not same) results on Debian Stable, gs 10.00.0 +& qpdf 11.3.0: + +# R CMD build --no-resave-data --compact-vignettes=both + compacted ?Vig_01_Start_Here.pdf? from 244Kb to 45Kb + compacted ?Vig_02_Conceptual_Intro_PCA.pdf? from 432Kb to 143Kb + compacted ?Vig_03_Step_By_Step_PCA.pdf? from 411Kb to 100Kb + compacted ?Vig_04_Scores_Loadings.pdf? from 335Kb to 78Kb + compacted ?Vig_05_Visualizing_PCA_3D.pdf? from 679Kb to 478Kb + compacted ?Vig_06_Math_Behind_PCA.pdf? from 556Kb to 145Kb + compacted ?Vig_07_Functions_PCA.pdf? from 378Kb to 89Kb + compacted ?Vig_08_Notes.pdf? from 239Kb to 39Kb + + +> - doc/Vig_01_Start_Here.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=49942)/(old=45101) = 1.10734 .. not worth using +> - doc/Vig_02_Conceptual_Intro_PCA.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using +> - doc/Vig_03_Step_By_Step_PCA.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using +> - doc/Vig_04_Scores_Loadings.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using +> - doc/Vig_05_Visualizing_PCA_3D.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using +> - doc/Vig_06_Math_Behind_PCA.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=816690)/(old=571493) = 1.42905 .. not worth using +> - doc/Vig_07_Functions_PCA.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using +> - doc/Vig_08_Notes.pdf: gs: res=0; + qpdf: res=0; +> ==> (new=40919)/(old=38953) = 1.05047 .. not worth using + +Thank you for providing this data! Somehow, instead of compacting the +PDFs, one of the tools manages to blow them up in size, as much as ~23 +times. + +Can you try tools::compactPDF() separately with gs_quality = 'none' +(isolating qpdf) and with qpdf = '' (isolating GhostScript)? + +If the culprit turns out to be GhostScript, it may be due to their +rewritten PDF rendering engine (now in C instead of PostScript with +special extensions) not being up to par when the PDF file needs to be +compressed. If it turns out to be qpdf, we might have to extract the +exact command lines and compare results further. + +-- +Best regards, +Ivan + + +From h@n@on @end|ng |rom dep@uw@edu Thu Apr 25 20:54:49 2024 +From: h@n@on @end|ng |rom dep@uw@edu (Bryan Hanson) +Date: Thu, 25 Apr 2024 11:54:49 -0700 +Subject: [R-pkg-devel] Some, but not all vignettes compressed +In-Reply-To: <20240425212640.39a2f275@Tarkus> +References: + <20240425212640.39a2f275@Tarkus> +Message-ID: <57FFC3BD-7767-4A8D-BD17-5C4B29421057@depauw.edu> + +Thank you so much Ivan for investigating. I didn?t even notice the *increase*! The results of the tests you requested are very interesting: + +R > tools::compactPDF("doc", gs_quality = "none", verbose = TRUE) +qs_quality="none" : use_gs=FALSE, use_qpdf=TRUE +#{pdf}s = length(paths) = 8 +- doc/Vig_01_Start_Here.pdf: only qpdf: res=0; + ==> (new=45281)/(old=45281) = 1 .. not worth using +- doc/Vig_02_Conceptual_Intro_PCA.pdf: only qpdf: res=0; + ==> (new=441808)/(old=442464) = 0.998517 .. not worth using +- doc/Vig_03_Step_By_Step_PCA.pdf: only qpdf: res=0; + ==> (new=422940)/(old=423750) = 0.998088 .. not worth using +- doc/Vig_04_Scores_Loadings.pdf: only qpdf: res=0; + ==> (new=342335)/(old=341955) = 1.00111 .. not worth using +- doc/Vig_05_Visualizing_PCA_3D.pdf: only qpdf: res=0; + ==> (new=692950)/(old=693206) = 0.999631 .. not worth using +- doc/Vig_06_Math_Behind_PCA.pdf: only qpdf: res=0; + ==> (new=571600)/(old=571761) = 0.999718 .. not worth using +- doc/Vig_07_Functions_PCA.pdf: only qpdf: res=0; + ==> (new=389451)/(old=389747) = 0.999241 .. not worth using +- doc/Vig_08_Notes.pdf: only qpdf: res=0; + ==> (new=39131)/(old=39131) = 1 .. not worth using + +Looks like my version of qpdf (which I think shipped with R) can?t reduce the sizes. + +R > tools::compactPDF("doc", gs_quality = "ebook", gs_cmd = "/opt/homebrew/bin/gs", verbose = TRUE, qpdf = "") +qs_quality="ebook" : use_gs=TRUE, use_qpdf=FALSE +#{pdf}s = length(paths) = 8 +- doc/Vig_01_Start_Here.pdf: gs: res=0; + ==> (new=50865)/(old=45281) = 1.12332 .. not worth using +- doc/Vig_02_Conceptual_Intro_PCA.pdf: gs: res=0; + ==> (new=1.00061e+07)/(old=442464) = 22.6146 .. not worth using +- doc/Vig_03_Step_By_Step_PCA.pdf: gs: res=0; + ==> (new=5.76371e+06)/(old=423750) = 13.6017 .. not worth using +- doc/Vig_04_Scores_Loadings.pdf: gs: res=0; + ==> (new=5.41358e+06)/(old=341955) = 15.8312 .. not worth using +- doc/Vig_05_Visualizing_PCA_3D.pdf: gs: res=0; + ==> (new=1.23619e+07)/(old=693206) = 17.833 .. not worth using +- doc/Vig_06_Math_Behind_PCA.pdf: gs: res=0; + ==> (new=818313)/(old=571761) = 1.43122 .. not worth using +- doc/Vig_07_Functions_PCA.pdf: gs: res=0; + ==> (new=1.36534e+06)/(old=389747) = 3.50315 .. not worth using +- doc/Vig_08_Notes.pdf: gs: res=0; + ==> (new=41780)/(old=39131) = 1.0677 .. not worth using + +So my version of gs blows things up! + +Also modified the above using gs_quality = ?printer? or ?screen? and the results are very similar. + +Bryan + + +> On Apr 25, 2024, at 11:26?AM, Ivan Krylov wrote: +> +> ? Thu, 25 Apr 2024 08:54:41 -0700 +> Bryan Hanson ?????: +> +>> 'gs+qpdf' made some significant size reductions: +>> compacted 'Vig_02_Conceptual_Intro_PCA.pdf' from 432Kb to 143Kb +>> compacted 'Vig_03_Step_By_Step_PCA.pdf' from 414Kb to 101Kb +>> compacted 'Vig_04_Scores_Loadings.pdf' from 334Kb to 78Kb +>> compacted 'Vig_06_Math_Behind_PCA.pdf' from 558Kb to 147Kb +>> compacted 'Vig_07_Functions_PCA.pdf' from 381Kb to 90Kb +> +> I'm getting similar (but not same) results on Debian Stable, gs 10.00.0 +> & qpdf 11.3.0: +> +> # R CMD build --no-resave-data --compact-vignettes=both +> compacted ?Vig_01_Start_Here.pdf? from 244Kb to 45Kb +> compacted ?Vig_02_Conceptual_Intro_PCA.pdf? from 432Kb to 143Kb +> compacted ?Vig_03_Step_By_Step_PCA.pdf? from 411Kb to 100Kb +> compacted ?Vig_04_Scores_Loadings.pdf? from 335Kb to 78Kb +> compacted ?Vig_05_Visualizing_PCA_3D.pdf? from 679Kb to 478Kb +> compacted ?Vig_06_Math_Behind_PCA.pdf? from 556Kb to 145Kb +> compacted ?Vig_07_Functions_PCA.pdf? from 378Kb to 89Kb +> compacted ?Vig_08_Notes.pdf? from 239Kb to 39Kb +> +> +>> - doc/Vig_01_Start_Here.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=49942)/(old=45101) = 1.10734 .. not worth using +>> - doc/Vig_02_Conceptual_Intro_PCA.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=1.00061e+07)/(old=442210) = 22.6275 .. not worth using +>> - doc/Vig_03_Step_By_Step_PCA.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=5.763e+06)/(old=423484) = 13.6085 .. not worth using +>> - doc/Vig_04_Scores_Loadings.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=5.41409e+06)/(old=341680) = 15.8455 .. not worth using +>> - doc/Vig_05_Visualizing_PCA_3D.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=1.23622e+07)/(old=692901) = 17.8412 .. not worth using +>> - doc/Vig_06_Math_Behind_PCA.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=816690)/(old=571493) = 1.42905 .. not worth using +>> - doc/Vig_07_Functions_PCA.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=1.36419e+06)/(old=389478) = 3.50262 .. not worth using +>> - doc/Vig_08_Notes.pdf: gs: res=0; + qpdf: res=0; +>> ==> (new=40919)/(old=38953) = 1.05047 .. not worth using +> +> Thank you for providing this data! Somehow, instead of compacting the +> PDFs, one of the tools manages to blow them up in size, as much as ~23 +> times. +> +> Can you try tools::compactPDF() separately with gs_quality = 'none' +> (isolating qpdf) and with qpdf = '' (isolating GhostScript)? +> +> If the culprit turns out to be GhostScript, it may be due to their +> rewritten PDF rendering engine (now in C instead of PostScript with +> special extensions) not being up to par when the PDF file needs to be +> compressed. If it turns out to be qpdf, we might have to extract the +> exact command lines and compare results further. +> +> -- +> Best regards, +> Ivan + +============= +Bryan A. Hanson +Prof. Emeritus, DePauw University +Chemistry & Biochemistry +hanson at depauw.edu +profbryanhanson at gmail.com +Nerdy blog: ChemoSpec.org +I?m at GMT -7 year round + + + + + + + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Thu Apr 25 21:36:51 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 25 Apr 2024 22:36:51 +0300 +Subject: [R-pkg-devel] Some, but not all vignettes compressed +In-Reply-To: <57FFC3BD-7767-4A8D-BD17-5C4B29421057@depauw.edu> +References: + <20240425212640.39a2f275@Tarkus> + <57FFC3BD-7767-4A8D-BD17-5C4B29421057@depauw.edu> +Message-ID: <20240425223651.79574bb7@Tarkus> + +? Thu, 25 Apr 2024 11:54:49 -0700 +Bryan Hanson ?????: + +> So my version of gs blows things up! + +The relatively good news is that GhostScript is not solely to blame. A +fresh build of "GPL Ghostscript 10.03.0 (2024-03-06)" was able to +reduce the files to 16..70% of their original size on my computer. But +I just typed ./configure && make and relied on the dependencies already +present on my system. + +We can try to compare the build settings (which will involve compiling +things by hand) or ask the Homebrew people [*] (and they will probably +ask for a PDF file and a specific command line that works on some +builds of gs-10.03.0 but not with Homebrew). + +What would you rather do? + +qpdf, on the other hand, results in no size reduction (99.7% or worse), +just like on your system. + +-- +Best regards, +Ivan + +[*] +https://docs.brew.sh/Troubleshooting +https://github.com/Homebrew/homebrew-core/issues?q=ghostscript + + +From |eo@m@d@ @end|ng |rom @yon|c@eu Fri Apr 26 23:49:47 2024 +From: |eo@m@d@ @end|ng |rom @yon|c@eu (Leo Mada) +Date: Fri, 26 Apr 2024 21:49:47 +0000 +Subject: [R-pkg-devel] Extending proj with proj.line3d methods and + overloading the methods +Message-ID: + +Dear List-Members, + +I try to implement a proj.line3d method and to overload this method as follows: + +proj.line3d <- function(p, x, y, z, ...) + UseMethod("proj.line3d") + +proj.line3d.numeric = function(p, x, y, z, ...) { + # ... +} + +proj.line3d.matrix = function(p, x, y, z, ...) { + # ... +} + +The code is available on GitHub, specifically in: +https://github.com/discoleo/Rpdb/blob/main/R/proj.R + + +However, I encountered various issues both with running proj.line3d and with documenting the functions in order to pass the CRAN-checks. + +# ERROR: Executing function + +p = c(1,2,3) +line = matrix(c(0,5,2,3,1,4), 2) +proj.line3d(p, line) +# Error in UseMethod("proj.line3d") : +# no applicable method for 'proj.line3d' applied to an object of class "c('double', 'numeric')" + +I do prefer to have the methods named as "proj._name_" so that they are easily searchable using methods(proj). It's possible to project a point on a line, or a point on a plane, or other more complex projections. Therefore, more methods are possible in the future. + +methods(proj) +# [1] proj.aov* proj.aovlist* proj.default* proj.line3d +# [5] proj.line3d.matrix proj.line3d.numeric proj.lm + +I think it is wise to solve first this issue before solving the documentation issues. + +Many thnaks, + +Leonard + + + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Sat Apr 27 09:08:57 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Sat, 27 Apr 2024 10:08:57 +0300 +Subject: [R-pkg-devel] Extending proj with proj.line3d methods and + overloading the methods +In-Reply-To: +References: +Message-ID: <31316745-EAB3-4083-B4B9-757142718797@disroot.org> + +27 ?????? 2024 ?. 00:49:47 GMT+03:00, Leo Mada via R-package-devel ?????: +>Dear List-Members, +> +>I try to implement a proj.line3d method and to overload this method as follows: +> +>proj.line3d <- function(p, x, y, z, ...) +> UseMethod("proj.line3d") +> +>proj.line3d.numeric = function(p, x, y, z, ...) { +> # ... +>} +> +>proj.line3d.matrix = function(p, x, y, z, ...) { +> # ... +>} + +>p = c(1,2,3) +>line = matrix(c(0,5,2,3,1,4), 2) +>proj.line3d(p, line) +># Error in UseMethod("proj.line3d") : +># no applicable method for 'proj.line3d' applied to an object of class "c('double', 'numeric')" + +>methods(proj) +># [1] proj.aov* proj.aovlist* proj.default* proj.line3d +># [5] proj.line3d.matrix proj.line3d.numeric proj.lm + +In your NAMESPACE, you've registered methods for the generic function 'proj', classes 'line3d.matrix' and 'line3d.numeric', but above you are calling a different generic, 'proj.line3d', for which no methods are registered. + +For proj.line3d(, ) to work, you'll have to register the methods for the proj.line3d generic. If you need a visible connection to the proj() generic, you can try registering a method on the 'proj' generic, class 'line3d' *and* creating a class 'line3d' that would wrap your vectors and matrices: + +proj(line3d(p), line) -> call lands in proj.line3d -> maybe additional dispatch on the remaining classes of 'p'? + +This seems to work, but I haven't tested it extensively: + +> proj.line3d <- \(x, ...) UseMethod('proj.line3d') +> proj.line3d.numeric <- \(x, ...) { message('proj.line3d.numeric'); x } +> line3d <- \(x) structure(x, class = c('line3d', class(x))) +> proj(line3d(pi)) +proj.line3d.numeric +[1] 3.141593 +attr(,"class") +[1] "line3d" "numeric" + +-- +Best regards, +Ivan + + +From |eo@m@d@ @end|ng |rom @yon|c@eu Sun Apr 28 17:15:06 2024 +From: |eo@m@d@ @end|ng |rom @yon|c@eu (Leo Mada) +Date: Sun, 28 Apr 2024 15:15:06 +0000 +Subject: [R-pkg-devel] Extending proj with proj.line3d methods and + overloading the methods +In-Reply-To: <31316745-EAB3-4083-B4B9-757142718797@disroot.org> +References: + <31316745-EAB3-4083-B4B9-757142718797@disroot.org> +Message-ID: + +Dear Ivan, + +Thank you very much for the response. + +Indeed, I was skeptical how R interprets class names and I have supposed it a little bit different. + +S3 methods are more like overloaded functions; while S4 methods are more like true methods implemented for a class. But this is very approximate (with many exceptions and anomalies); and many programmers are not used to think like this. + +The "proj" class could have both overloaded functions (e.g. for aov class, ...), and also new methods like projection of a point on a line, or projection of a point on a plane (which are still projections). + +This is why I intended to define a new method "proj.line3d" and overload this method. But it seems that R interprets "line3d.numeric" as a class - which originates probably from the "data,frame" class. + +How can I define a real method "proj.line3d"? +There might be some limitations from Roxygen as well (as I use it for the package); but it might be easier to proceed, once I understand how to do it in R. + +I thought that this solves the problem: +proj.line3d <- function(p, x, y, z, ...) + UseMethod("proj.line3d") + +And maybe it did what I intended. But I need to "register" the overloaded functions somehow differently? + +The other solution, as you pointed out, is more cumbersome; and it needs 2 separate classes, so I would need to define "proj" as an S4 class (as S3 does not handle 2 classes at once). + + +Thank you very much, + +Leonard + + + +________________________________ +From: Ivan Krylov +Sent: Saturday, April 27, 2024 10:08 AM +To: Leo Mada ; r-package-devel at r-project.org +Subject: Re: [R-pkg-devel] Extending proj with proj.line3d methods and overloading the methods + +27 ?????? 2024 ?. 00:49:47 GMT+03:00, Leo Mada via R-package-devel ?????: +>Dear List-Members, +> +>I try to implement a proj.line3d method and to overload this method as follows: +> +>proj.line3d <- function(p, x, y, z, ...) +> UseMethod("proj.line3d") +> +>proj.line3d.numeric = function(p, x, y, z, ...) { +> # ... +>} +> +>proj.line3d.matrix = function(p, x, y, z, ...) { +> # ... +>} + +>p = c(1,2,3) +>line = matrix(c(0,5,2,3,1,4), 2) +>proj.line3d(p, line) +># Error in UseMethod("proj.line3d") : +># no applicable method for 'proj.line3d' applied to an object of class "c('double', 'numeric')" + +>methods(proj) +># [1] proj.aov* proj.aovlist* proj.default* proj.line3d +># [5] proj.line3d.matrix proj.line3d.numeric proj.lm + +In your NAMESPACE, you've registered methods for the generic function 'proj', classes 'line3d.matrix' and 'line3d.numeric', but above you are calling a different generic, 'proj.line3d', for which no methods are registered. + +For proj.line3d(, ) to work, you'll have to register the methods for the proj.line3d generic. If you need a visible connection to the proj() generic, you can try registering a method on the 'proj' generic, class 'line3d' *and* creating a class 'line3d' that would wrap your vectors and matrices: + +proj(line3d(p), line) -> call lands in proj.line3d -> maybe additional dispatch on the remaining classes of 'p'? + +This seems to work, but I haven't tested it extensively: + +> proj.line3d <- \(x, ...) UseMethod('proj.line3d') +> proj.line3d.numeric <- \(x, ...) { message('proj.line3d.numeric'); x } +> line3d <- \(x) structure(x, class = c('line3d', class(x))) +> proj(line3d(pi)) +proj.line3d.numeric +[1] 3.141593 +attr(,"class") +[1] "line3d" "numeric" + +-- +Best regards, +Ivan + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Sun Apr 28 20:15:42 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Sun, 28 Apr 2024 21:15:42 +0300 +Subject: [R-pkg-devel] Extending proj with proj.line3d methods and + overloading the methods +In-Reply-To: +References: + <31316745-EAB3-4083-B4B9-757142718797@disroot.org> + +Message-ID: <20240428211542.29f82804@trisector> + +? Sun, 28 Apr 2024 15:15:06 +0000 +Leo Mada ?????: + +> This is why I intended to define a new method "proj.line3d" and +> overload this method. But it seems that R interprets "line3d.numeric" +> as a class - which originates probably from the "data,frame" class. + +It may help to call the original 'proj' function and your new +'proj.line3d' function "generics", because that's what most S3 +literature calls these functions that you overload. This separates them +from the "methods" 'proj.line3d.numeric' and 'proj.line3d.matrix' that +can be said to "implement" or "overload" the generic. + +A concise but very readable guide to S3 and other built-in OOP systems +in R can be found in Advanced R by Hadley Wickham: +http://adv-r.had.co.nz/OO-essentials.html#s3 + +> How can I define a real method "proj.line3d"? + +In order to export an S3 generic and register methods for it from a +package, you need the following directives in your NAMESPACE: + +export(proj.line3d) +S3method(proj.line3d, numeric) # will use function proj.line3d.numeric +S3method(proj.line3d, matrix) # similar + + + +> There might be some limitations from Roxygen as well (as I use it for +> the package); but it might be easier to proceed, once I understand +> how to do it in R. + +The roxygen2 documentation says that if there are multiple dots in the +name of a function, you need to use the two-argument form of the +@method keyword: @method proj.line3d numeric (untested). + + +> I thought that this solves the problem: +> proj.line3d <- function(p, x, y, z, ...) +> UseMethod("proj.line3d") + +Right. This is the definition of an S3 generic generic in R. As long as +all the methods will also accept arguments (p, x, y, z, , ), all will be fine. + +> The other solution, as you pointed out, is more cumbersome; and it +> needs 2 separate classes, so I would need to define "proj" as an S4 +> class (as S3 does not handle 2 classes at once). + +Moreover, you still need an exported generic proj.line3d and registered +methods for it to work. Inheritance does work in S3 (see NextMethod()), +but it alone won't help you call proj.line3d.numeric() from proj() and +'numeric' x. + +-- +Best regards, +Ivan + + +From ro||turner @end|ng |rom po@teo@net Mon Apr 29 03:19:50 2024 +From: ro||turner @end|ng |rom po@teo@net (Rolf Turner) +Date: Mon, 29 Apr 2024 01:19:50 +0000 +Subject: [R-pkg-devel] Problem with loading package "devtools" from CRAN. +Message-ID: <20240429131950.43264267@rolf-Latitude-E7470> + + +Executive summary: + +> The devtools package on CRAN appears to be broken. +> Installing devtools from github (using remotes::install_github()) +> seems to give satisfactory results. + +This morning my software up-dater (Ubuntu 22.04.4) prompted me to +install updated versions of some software, including r-base. I thereby +obtained what I believe is the latest version of R (4.4.0 (2024-04-24)). + +Then I could not load the "devtools" package, which is fairly crucial to +my work. + +A bit of web-searching got me to a post on github by Henrik Bengtsson, +which referred to the devtools problem. I therefore decided to try +installing devtools from github: + + remotes::install_github("r-lib/devtools",lib="/home/rolf/Rlib") + +Some 50-odd packages seemed to require up-dating. I went for it, and +after a fairly long wait, while messages about the updating flowed by, +devtools seemed to get installed. Now "library(devtools)" runs without +error, so I am happy with my own situation. However there seems to be +a problem with the devtools package on CRAN, which ought to be fixed. + +cheers, + +Rolf Turner + +-- +Honorary Research Fellow +Department of Statistics +University of Auckland +Stats. Dep't. (secretaries) phone: + +64-9-373-7599 ext. 89622 +Home phone: +64-9-480-4619 + + +From berw|n@tur|@ch @end|ng |rom gm@||@com Mon Apr 29 08:27:42 2024 +From: berw|n@tur|@ch @end|ng |rom gm@||@com (Berwin A Turlach) +Date: Mon, 29 Apr 2024 14:27:42 +0800 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <20240429131950.43264267@rolf-Latitude-E7470> +References: <20240429131950.43264267@rolf-Latitude-E7470> +Message-ID: <20240429142742.7e355d89@dep59159.uniwa.uwa.edu.au> + +G'day Rolf, + +hope all is well. + +On Mon, 29 Apr 2024 01:19:50 +0000 +Rolf Turner wrote: + +> Executive summary: +> +> > The devtools package on CRAN appears to be broken. +> > Installing devtools from github (using remotes::install_github()) +> > seems to give satisfactory results. + +I somehow have not shared this experience. But then I compile on my +machines (Ubuntu 22.04.4) R and packages from source. + +For me the devtools package from CRAN seems to work fine with R 4.4.0 + +> [...] I thereby obtained what I believe is the latest version of R +> (4.4.0 (2024-04-24)). + +Well, what happens if you start R and enter "R.version"? That should +confirm whether you run R 4.4.0. :) + +If you run R 4.4.0 but previously ran R 4.3.x then you are running now +a version with a new minor version number. AFAIK, there is no +guarantee that at the interface level to compiled code R versions +remain compatible when the minor version number changes. + +So on machines where I do not compile from source, I usually run +"update.packages(checkBuilt=TRUE)" whenever I upgrade R on those +machines, definitely if the upgrade involves a change in the major or +minor version number. + +Did you try updating your packages? + +Well, you probably first want to find out where exactly the Debian R +distribution installs additional packages (Dirk might help there), and +it might be that you have to run either (or all) of: + +update.packages(lib="/usr/local/lib/R/site-library", checkBuilt=TRUE) +update.packages(lib="/usr/lib/R/site-library", checkBuilt=TRUE) +update.packages(lib="/usr/lib/R/library", checkBuilt=TRUE) + +though, by a short look at my Ubuntu machine, it may be that the last +two locations are not writeable for you as user, and the first one only +if you belong to the group "staff" as normal user on your machine. + +> A bit of web-searching got me to a post on github by Henrik Bengtsson, +> which referred to the devtools problem. + +Could you provide a link? I could not find anything relevant. :) + +> However there seems to be a problem with the devtools package on +> CRAN, which ought to be fixed. + +Or, perhaps, just that the interface to compiled code changed from R +3.6.x to R 4.4.0 and, hence, all packages that rely on compiled code +must be reinstalled. + +Stay safe. + +Cheers, + + Berwin + + +From @|mon@urb@nek @end|ng |rom R-project@org Mon Apr 29 08:33:55 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Mon, 29 Apr 2024 18:33:55 +1200 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <20240429131950.43264267@rolf-Latitude-E7470> +References: <20240429131950.43264267@rolf-Latitude-E7470> +Message-ID: <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> + +Rolf, + +what do you mean by "broken"? Since you failed to include any proof nor details it's unlikely that anyone can help you, but chances are pretty high that it was a problem on your end. I just checked with R 4.4.0 on Ubuntu 22.04 and devtools install and load just fine, so it is certainly broken on CRAN. + +Make sure you don't have packages for old R version in your local libraries - that is a most common mistake - always remove them when upgrading R and re-install if still need them. You can check the locations of your libraries with .libPaths() in R. Sometimes, update.packages(checkBuilt=TRUE) can do the trick as well, but I prefer clean re-installs for safety as it also helps you clean up old cruft that is not longer needed. + +Cheers, +Simon + + + +> On Apr 29, 2024, at 1:19 PM, Rolf Turner wrote: +> +> +> Executive summary: +> +>> The devtools package on CRAN appears to be broken. +>> Installing devtools from github (using remotes::install_github()) +>> seems to give satisfactory results. +> +> This morning my software up-dater (Ubuntu 22.04.4) prompted me to +> install updated versions of some software, including r-base. I thereby +> obtained what I believe is the latest version of R (4.4.0 (2024-04-24)). +> +> Then I could not load the "devtools" package, which is fairly crucial to +> my work. +> +> A bit of web-searching got me to a post on github by Henrik Bengtsson, +> which referred to the devtools problem. I therefore decided to try +> installing devtools from github: +> +> remotes::install_github("r-lib/devtools",lib="/home/rolf/Rlib") +> +> Some 50-odd packages seemed to require up-dating. I went for it, and +> after a fairly long wait, while messages about the updating flowed by, +> devtools seemed to get installed. Now "library(devtools)" runs without +> error, so I am happy with my own situation. However there seems to be +> a problem with the devtools package on CRAN, which ought to be fixed. +> +> cheers, +> +> Rolf Turner +> +> -- +> Honorary Research Fellow +> Department of Statistics +> University of Auckland +> Stats. Dep't. (secretaries) phone: +> +64-9-373-7599 ext. 89622 +> Home phone: +64-9-480-4619 +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +From georg|@bo@hn@kov @end|ng |rom m@nche@ter@@c@uk Mon Apr 29 08:54:16 2024 +From: georg|@bo@hn@kov @end|ng |rom m@nche@ter@@c@uk (Georgi Boshnakov) +Date: Mon, 29 Apr 2024 06:54:16 +0000 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> +References: <20240429131950.43264267@rolf-Latitude-E7470> + <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> +Message-ID: + +I also had the problem that devtools didn't install. + +I used update.packages(ask =FALSE) and that solved the problem. + +Before that I tried to locate the culprit but it was not one of the direct dependencies of devtools. + +Georgi Boshnakov + +Sent from Outlook for Android +________________________________ +From: R-package-devel on behalf of Simon Urbanek +Sent: Monday, April 29, 2024 7:33:55 AM +To: Rolf Turner +Cc: jenny at posit.co ; r-package-devel at r-project.org +Subject: Re: [R-pkg-devel] Problem with loading package "devtools" from CRAN. + +Rolf, + +what do you mean by "broken"? Since you failed to include any proof nor details it's unlikely that anyone can help you, but chances are pretty high that it was a problem on your end. I just checked with R 4.4.0 on Ubuntu 22.04 and devtools install and load just fine, so it is certainly broken on CRAN. + +Make sure you don't have packages for old R version in your local libraries - that is a most common mistake - always remove them when upgrading R and re-install if still need them. You can check the locations of your libraries with .libPaths() in R. Sometimes, update.packages(checkBuilt=TRUE) can do the trick as well, but I prefer clean re-installs for safety as it also helps you clean up old cruft that is not longer needed. + +Cheers, +Simon + + + +> On Apr 29, 2024, at 1:19 PM, Rolf Turner wrote: +> +> +> Executive summary: +> +>> The devtools package on CRAN appears to be broken. +>> Installing devtools from github (using remotes::install_github()) +>> seems to give satisfactory results. +> +> This morning my software up-dater (Ubuntu 22.04.4) prompted me to +> install updated versions of some software, including r-base. I thereby +> obtained what I believe is the latest version of R (4.4.0 (2024-04-24)). +> +> Then I could not load the "devtools" package, which is fairly crucial to +> my work. +> +> A bit of web-searching got me to a post on github by Henrik Bengtsson, +> which referred to the devtools problem. I therefore decided to try +> installing devtools from github: +> +> remotes::install_github("r-lib/devtools",lib="/home/rolf/Rlib") +> +> Some 50-odd packages seemed to require up-dating. I went for it, and +> after a fairly long wait, while messages about the updating flowed by, +> devtools seemed to get installed. Now "library(devtools)" runs without +> error, so I am happy with my own situation. However there seems to be +> a problem with the devtools package on CRAN, which ought to be fixed. +> +> cheers, +> +> Rolf Turner +> +> -- +> Honorary Research Fellow +> Department of Statistics +> University of Auckland +> Stats. Dep't. (secretaries) phone: +> +64-9-373-7599 ext. 89622 +> Home phone: +64-9-480-4619 +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!D1bv6hCvIc_G_5ay6dqpVMj1roESgfSV8NT0AaMD8kJ92-7-YAkFg6c4TaVx-GXHEj7yieujSDu7LATDgtP-aSPQ7C2b745lri9DbFpH$ [stat[.]ethz[.]ch] +> + +______________________________________________ +R-package-devel at r-project.org mailing list +https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-package-devel__;!!PDiH4ENfjr2_Jw!D1bv6hCvIc_G_5ay6dqpVMj1roESgfSV8NT0AaMD8kJ92-7-YAkFg6c4TaVx-GXHEj7yieujSDu7LATDgtP-aSPQ7C2b745lri9DbFpH$ [stat[.]ethz[.]ch] + + [[alternative HTML version deleted]] + + +From edd @end|ng |rom deb|@n@org Mon Apr 29 13:30:20 2024 +From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel) +Date: Mon, 29 Apr 2024 06:30:20 -0500 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: +References: <20240429131950.43264267@rolf-Latitude-E7470> + <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> + +Message-ID: <26159.33996.203015.970788@rob.eddelbuettel.com> + + +Rolf, + +This question might have been more appropriate for r-sig-debian than here. +But as Simon noted, the lack of detail makes is difficult to say anything to +aid. It likely was an issue local to your setup and use. + +These days, I strongly recommend r2u [1]. As you already use R via CRAN +through apt, r2u adds one more repository after which _all_ R packages are +handled via the same apt operations that you already trust to get you R from +CRAN (as well as anything else on your machine). This covers all 20+ +thousand CRAN packages along with 400 key BioC packages. Handling your +packages with your system package managed guarantees all dependencies are +resolved reliably and quickly. It makes installing, upgrading, managing CRAN +package easier, faster and more reliable. + +To double-check, I just spot-checked 'devtools' on an r2u container (on top +of Ubuntu 22.04) and of course devtools install and runs fine (as a binary). +So maybe give r2u a go. "Sixteen million packages served" in two years ... + +Cheers, Dirk + +[1] https://eddelbuettel.github.io/r2u + +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + + +From ro||turner @end|ng |rom po@teo@net Tue Apr 30 03:21:15 2024 +From: ro||turner @end|ng |rom po@teo@net (Rolf Turner) +Date: Tue, 30 Apr 2024 01:21:15 +0000 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <26159.33996.203015.970788@rob.eddelbuettel.com> +References: <20240429131950.43264267@rolf-Latitude-E7470> + <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> + + <26159.33996.203015.970788@rob.eddelbuettel.com> +Message-ID: <20240430132115.7b9fab83@rolf-Latitude-E7470> + + +Well, I just uninstalled the devtools that I had installed from github +and ran + + install.packages("devtools",lib="/home/rolf/Rlib") + +No error message this time; the install went just fine. +The explanation may lie in the plethora of packages that I re-installed +when I invoked + + remotes::install_github("r-lib/devtools",lib="/home/rolf/Rlib") + +This probably relates to Simon Urbanek's advice to re-install all +packages in my local library. Which I will make sure to do in future. + +Previously I got an error message from + + install.packages("devtools",lib="/home/rolf/Rlib") + +but now of course I cannot reproduce it. + +On Mon, 29 Apr 2024 06:30:20 -0500 +Dirk Eddelbuettel wrote: + + + +> These days, I strongly recommend r2u [1]. As you already use R via +> CRAN through apt, r2u adds one more repository after which _all_ R +> packages are handled via the same apt operations that you already +> trust to get you R from CRAN (as well as anything else on your +> machine). This covers all 20+ thousand CRAN packages along with 400 +> key BioC packages. Handling your packages with your system package +> managed guarantees all dependencies are resolved reliably and +> quickly. It makes installing, upgrading, managing CRAN package +> easier, faster and more reliable. + + + +> [1] https://eddelbuettel.github.io/r2u + + + +Sounds promising, but I cannot follow what "r2u" is actually +all about. What *is* r2u? And how do I go about using it? Do I +invoke it (or invoke something) from within R? Or do I invoke +something from the OS? E.g. something like + +sudo apt-get install + +??? + +I have downloaded the file add_cranapt_jammy.sh and executed + + sudo sh add_cranapt_jammy.sh + +which seemed to run OK. What now? + +cheers, + +Rolf + +-- +Honorary Research Fellow +Department of Statistics +University of Auckland +Stats. Dep't. (secretaries) phone: + +64-9-373-7599 ext. 89622 +Home phone: +64-9-480-4619 + + +From edd @end|ng |rom deb|@n@org Tue Apr 30 03:39:33 2024 +From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel) +Date: Mon, 29 Apr 2024 20:39:33 -0500 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <20240430132115.7b9fab83@rolf-Latitude-E7470> +References: <20240429131950.43264267@rolf-Latitude-E7470> + <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> + + <26159.33996.203015.970788@rob.eddelbuettel.com> + <20240430132115.7b9fab83@rolf-Latitude-E7470> +Message-ID: <26160.19413.125681.947133@rob.eddelbuettel.com> + + +On 30 April 2024 at 01:21, Rolf Turner wrote: +| On Mon, 29 Apr 2024 06:30:20 -0500 +| Dirk Eddelbuettel wrote: +| +| +| +| > These days, I strongly recommend r2u [1]. As you already use R via +| > CRAN through apt, r2u adds one more repository after which _all_ R +| > packages are handled via the same apt operations that you already +| > trust to get you R from CRAN (as well as anything else on your +| > machine). This covers all 20+ thousand CRAN packages along with 400 +| > key BioC packages. Handling your packages with your system package +| > managed guarantees all dependencies are resolved reliably and +| > quickly. It makes installing, upgrading, managing CRAN package +| > easier, faster and more reliable. +| +| +| +| > [1] https://eddelbuettel.github.io/r2u +| +| +| +| Sounds promising, but I cannot follow what "r2u" is actually +| all about. What *is* r2u? And how do I go about using it? Do I +| invoke it (or invoke something) from within R? Or do I invoke +| something from the OS? E.g. something like +| +| sudo apt-get install +| +| ??? + +You could peruse the documentation at + + https://eddelbuettel.github.io/r2u + +and / or the blogposts I have especially below + + https://dirk.eddelbuettel.com/blog/code/r4/ + +(and you may have to read 'in reverse order'). + +| I have downloaded the file add_cranapt_jammy.sh and executed +| +| sudo sh add_cranapt_jammy.sh +| +| which seemed to run OK. What now? + +Briefly, when you setup r2u you set up new a new apt repo AND a new way to +access them from R (using the lovely `bspm` package). So in R saying +`install.packages("devtools")` will seamlessly fetch r-cran-devtools and +about 100 other files it depends upon (if you start from an 'empty' system as +I did in a container last eve before replying to you). That works in mere +seconds. You can then say `library(devtools)` as if you compiled locally. + +Naturally, using binaries both way faster and easier when it works (as this +generally does). See the blog posts, see the demos, see the r2u site, try in +(risklessly !!) in a container or at gitpod or in continuous integration or +in codespaces or ... + +The docs try to get to that. Maybe start small and aim `install.packages()` +at a package you know you do not have see what what happens? + +Follow-ups may be more appropriate for r-sig-debian, and/or an issue ticket +at the r2u github repo depending on nature of the follow-up. + +Good luck, Dirk + + +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + + +From berw|n@tur|@ch @end|ng |rom gm@||@com Tue Apr 30 03:43:31 2024 +From: berw|n@tur|@ch @end|ng |rom gm@||@com (Berwin A Turlach) +Date: Tue, 30 Apr 2024 09:43:31 +0800 +Subject: [R-pkg-devel] + Problem with loading package "devtools" from CRAN. +In-Reply-To: <20240430132115.7b9fab83@rolf-Latitude-E7470> +References: <20240429131950.43264267@rolf-Latitude-E7470> + <3CB83F57-1943-4FF3-AF77-61F3DC111991@R-project.org> + + <26159.33996.203015.970788@rob.eddelbuettel.com> + <20240430132115.7b9fab83@rolf-Latitude-E7470> +Message-ID: <20240430094331.6fb0cf60@absentia> + +G'day Rolf, + +On Tue, 30 Apr 2024 01:21:15 +0000 +Rolf Turner wrote: + +> Previously I got an error message from +> +> install.packages("devtools",lib="/home/rolf/Rlib") +> +> but now of course I cannot reproduce it. + +Presumably the install.packages() invocation did not produce an error +message but a subsequent "library(devtools)" did? + +I am not sure how remotes::install_github() behaves. Are you using R +directly or via RStudio? RStudio redefines the behaviour of +install.packages() so I am not sure what would happen if you type that +command into an R session running in RStudio. + +As far as I remember, R's install.packages(), as you would invoke it if +you used R directly, installs the requested packages and any of its +(Depends/Imports) dependencies if these dependencies do not exist in +your libraries. As devtool's dependencies must have existed on your +system, your command only re-installed devtools but none of the +dependencies. + +And it must be one of the dependencies that uses compiled code and +created the problem, as a "packageDescription("devtools")" actually +shows "NeedsCompilation: no". + +You should really execute an + update.packages(lib="/home/rolf/Rlib", checkBuilt=TRUE) +whenever you upgrade your R version, definitely when the upgrade +involves changing the major/minor version. + +Cheers, + + Berwin + + +From kev|n@r@coombe@ @end|ng |rom gm@||@com Tue Apr 30 20:03:31 2024 +From: kev|n@r@coombe@ @end|ng |rom gm@||@com (Kevin R. Coombes) +Date: Tue, 30 Apr 2024 14:03:31 -0400 +Subject: [R-pkg-devel] re-exporting plot method? +Message-ID: <422b1f93-c779-40fd-a492-c6656960b354@gmail.com> + +Hi, + +I am working on a new package that primarily makes use of "igraph" +representations of certain mathematical graphs, in order to apply lots +of the comp sci algorithms already implemented in that package. For +display purposes, my "igraph" objects already include information that +defines node shapes and colors and edge styles and colors. But, I +believe that the "graph" - "Rgraphviz" - "graphNEL" set of tools will +produce better plots of the graphs. + +So, I wrote my own "as.graphNEL" function that converts the "igraph" +objects I want to use into graphNEL (or maybe into "Ragraph") format in +order to be able to use their graph layout and rendering routines. This +function is smart enough to translate the node and edge attributes from +igraph into something that works correctly when plotted using the tools +in Rgraphviz. (My DESCRIPTION and NAMESPACE files already import the set +of functions from Rgraphviz necessary to make this happen.) + +In principle, I'd like the eventual user to simply do something like + +library("KevinsNewPackage") +IG <- makeIgraphFromFile(sourcefile) +GN <- as.graphNEL(IG) +plot(GN) + +The first three lines work fine, but the "plot" function only works if +the user also explicitly includes the line + +library("Rgraphviz") + +I suspect that there is a way with imports and exports in the NAMESPACE +to make this work without having to remind the user to load the other +package. But (in part because the plot function in Rgraphviz is actually +an S4 method, which I don't need to alter in any way), I'm not sure +exactly what needs to be imported or exported. + +Helpful suggestion would be greatly appreciated. + +Best, + ? Kevin + + +From @|mon@urb@nek @end|ng |rom R-project@org Wed May 1 05:46:32 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Wed, 1 May 2024 15:46:32 +1200 +Subject: [R-pkg-devel] re-exporting plot method? +In-Reply-To: <422b1f93-c779-40fd-a492-c6656960b354@gmail.com> +References: <422b1f93-c779-40fd-a492-c6656960b354@gmail.com> +Message-ID: + +Kevin, + +welcome to the S4 world! ;) There is really no good solution since S4 only works at all if you attach the package since it relies on replacing the base S3 generic with its own - so the question remains what are your options to do it. + +The most obvious is to simply add Depends: Rgraphviz which makes sure that any generics required are attached so your package doesn't need to worry. This is the most reliable in a way as you are not limiting the functionality to methods you know about. The side-effect, though, (beside exposing functions the user may not care about) is that such package cannot be on CRAN since Rgraphics is not on CRAN (that said, you mentioned you are already importing then you seem not to worry about that). + +The next option is to simply ignore Rgraphviz and instead add setGeneric("plot") to your package and add methods to Depends and importFrom(methods, setGeneric) + exportMethods(plot) to the namespace. This allows you to forget about any dependencies - you are just creating the S4 generic from base::plot to make the dispatch work. This is the most light-weight solution as you only cherry-pick methods you need and there are no dependencies other than "methods". However, it is limited to just the functions you care about. + +Finally, you could re-export the S4 plot generic from Rgraphviz, but I'd say that is the least sensible option, since it doesn't have any benefit over doing it yourself and only adds a hard dependency for no good reason. Also copying functions from another package opens up a can of worms with versions etc. - even if the risk is likely minimal. + +Just for completeness - a really sneaky way would be to export an S3 plot method from your package - it would be only called in the case where the plot generic has not been replaced yet, so you could "fix" things on the fly by calling the generic from Rgraphviz, but that sounds a little hacky even for my taste ;). + +Cheers, +Simon + + + +> On 1/05/2024, at 6:03 AM, Kevin R. Coombes wrote: +> +> Hi, +> +> I am working on a new package that primarily makes use of "igraph" representations of certain mathematical graphs, in order to apply lots of the comp sci algorithms already implemented in that package. For display purposes, my "igraph" objects already include information that defines node shapes and colors and edge styles and colors. But, I believe that the "graph" - "Rgraphviz" - "graphNEL" set of tools will produce better plots of the graphs. +> +> So, I wrote my own "as.graphNEL" function that converts the "igraph" objects I want to use into graphNEL (or maybe into "Ragraph") format in order to be able to use their graph layout and rendering routines. This function is smart enough to translate the node and edge attributes from igraph into something that works correctly when plotted using the tools in Rgraphviz. (My DESCRIPTION and NAMESPACE files already import the set of functions from Rgraphviz necessary to make this happen.) +> +> In principle, I'd like the eventual user to simply do something like +> +> library("KevinsNewPackage") +> IG <- makeIgraphFromFile(sourcefile) +> GN <- as.graphNEL(IG) +> plot(GN) +> +> The first three lines work fine, but the "plot" function only works if the user also explicitly includes the line +> +> library("Rgraphviz") +> +> I suspect that there is a way with imports and exports in the NAMESPACE to make this work without having to remind the user to load the other package. But (in part because the plot function in Rgraphviz is actually an S4 method, which I don't need to alter in any way), I'm not sure exactly what needs to be imported or exported. +> +> Helpful suggestion would be greatly appreciated. +> +> Best, +> Kevin +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +From konr@d@rudo|ph @end|ng |rom gm@||@com Wed May 1 13:02:45 2024 +From: konr@d@rudo|ph @end|ng |rom gm@||@com (Konrad Rudolph) +Date: Wed, 1 May 2024 13:02:45 +0200 +Subject: [R-pkg-devel] May .External2() be used in packages? +Message-ID: + +Hello, + +Is the `.External2()` function part of the public API, and can it be used +in R packages submitted to CRAN? I would like to start using it in a +package, and there *are* packages on CRAN which use it. But its man page +[1] calls it ?internal?, R-exts doesn?t mention it at all (unlike `.C()`, +`.Call()` and `.External()`), and it doesn?t have any actual documentation. +In the context of the recent tightening of the C API CRAN rules, this makes +me concerned that `.External2()` might be next on the chopping block. + +[1] +https://stat.ethz.ch/R-manual/R-devel/library/base/html/Foreign-internal.html + +Cheers, + +-- +Konrad Rudolph // @klmr + + [[alternative HTML version deleted]] + + +From iuke-tier@ey m@iii@g oii uiow@@edu Wed May 1 20:35:48 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Wed, 1 May 2024 13:35:48 -0500 (CDT) +Subject: [R-pkg-devel] [External] May .External2() be used in packages? +In-Reply-To: +References: +Message-ID: <421bdf2-aa7c-983d-2687-1e83dc20bfcd@uiowa.edu> + +.External2() is not in the API and is not intended to be used in +packages. Packages that for whatever reason have chosen to use it +could instead use .External(), and that is what yo should use. I don't +expect that to be enforced by the check code soon, but it might be. + +[.External2() exists for historical reason to ease moving things that +used to be primitives in base out into packages where they fit more +naturally. It could be removed now, but I don't think that is high on +anyone's priority list.] + +Best, + +luke + +On Wed, 1 May 2024, Konrad Rudolph wrote: + +> Hello, +> +> Is the `.External2()` function part of the public API, and can it be used +> in R packages submitted to CRAN? I would like to start using it in a +> package, and there *are* packages on CRAN which use it. But its man page +> [1] calls it ?internal?, R-exts doesn?t mention it at all (unlike `.C()`, +> `.Call()` and `.External()`), and it doesn?t have any actual documentation. +> In the context of the recent tightening of the C API CRAN rules, this makes +> me concerned that `.External2()` might be next on the chopping block. +> +> [1] +> https://stat.ethz.ch/R-manual/R-devel/library/base/html/Foreign-internal.html +> +> Cheers, +> +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu/ + +From konr@d@rudo|ph @end|ng |rom gm@||@com Wed May 1 21:06:23 2024 +From: konr@d@rudo|ph @end|ng |rom gm@||@com (Konrad Rudolph) +Date: Wed, 1 May 2024 21:06:23 +0200 +Subject: [R-pkg-devel] [External] May .External2() be used in packages? +In-Reply-To: <421bdf2-aa7c-983d-2687-1e83dc20bfcd@uiowa.edu> +References: + <421bdf2-aa7c-983d-2687-1e83dc20bfcd@uiowa.edu> +Message-ID: + +Thanks, + +That?s a shame but good to know. + +Packages that for whatever reason have chosen to use it +> could instead use .External(), and that is what yo should use. + + +Unfortunately .External() is not a replacement (in general, or for my +purpose) since it?s missing the `call` and `rho` arguments, and computing +the same information without these arguments in C code is far from trivial. + +-- +Konrad Rudolph // @klmr + + [[alternative HTML version deleted]] + + +From iuke-tier@ey m@iii@g oii uiow@@edu Wed May 1 21:32:17 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Wed, 1 May 2024 14:32:17 -0500 (CDT) +Subject: [R-pkg-devel] [External] May .External2() be used in packages? +In-Reply-To: +References: + <421bdf2-aa7c-983d-2687-1e83dc20bfcd@uiowa.edu> + +Message-ID: + +yOn Wed, 1 May 2024, Konrad Rudolph wrote: + +> Thanks, +> +> That?s a shame but good to know. +> +> Packages that for whatever reason have chosen to use it +> could instead use .External(), and that is what yo should use. +> +> +> Unfortunately .External() is not a replacement (in general, or for my +> purpose) since it?s missing the `call` and `rho` arguments, and computing +> the same information without these arguments in C code is far from trivial. + +The call you would get is not likely to be all that useful, but it is +the one you wrote. The environment is the one you get from environment() +at the point where you would call .External2. So instead of + +.External2("foo", x, y) + +do + +.External("foo", quote(.External2("foo", x, y)), environment(), x, y) + +and adjust your C function accordingly. + +Best, + +luke + +> -- +> Konrad Rudolph // @klmr +> +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu + +From konr@d@rudo|ph @end|ng |rom gm@||@com Wed May 1 21:59:05 2024 +From: konr@d@rudo|ph @end|ng |rom gm@||@com (Konrad Rudolph) +Date: Wed, 1 May 2024 21:59:05 +0200 +Subject: [R-pkg-devel] [External] May .External2() be used in packages? +In-Reply-To: +References: + <421bdf2-aa7c-983d-2687-1e83dc20bfcd@uiowa.edu> + + +Message-ID: + +Hi Luke, + +Thanks, obviously that will work and I didn?t think of it. + +In my defence I had previously used match.call() to capture the call on the +R side, and representative microbenchmarks show that it adds a prohibitive +overhead for my use-case. On the C side I only need the caller information +in the non-performance sensitive path (for error message formatting) so I +can compute it on demand. And I hadn?t included .External2() in that +benchmark yet. I assume that it?ll be no faster than the way you proposed, +so it isn?t actually needed in my case ? just as you said. + + +On Wed, 1 May 2024 at 21:32, wrote: + +> yOn Wed, 1 May 2024, Konrad Rudolph wrote: +> +> > Thanks, +> > +> > That?s a shame but good to know. +> > +> > Packages that for whatever reason have chosen to use it +> > could instead use .External(), and that is what yo should use. +> > +> > +> > Unfortunately .External() is not a replacement (in general, or for my +> > purpose) since it?s missing the `call` and `rho` arguments, and computing +> > the same information without these arguments in C code is far from +> trivial. +> +> The call you would get is not likely to be all that useful, but it is +> the one you wrote. The environment is the one you get from environment() +> at the point where you would call .External2. So instead of +> +> .External2("foo", x, y) +> +> do +> +> .External("foo", quote(.External2("foo", x, y)), environment(), x, y) +> +> and adjust your C function accordingly. +> +> Best, +> +> luke +> +> > -- +> > Konrad Rudolph // @klmr +> > +> > +> +> -- +> Luke Tierney +> Ralph E. Wareham Professor of Mathematical Sciences +> University of Iowa Phone: 319-335-3386 +> Department of Statistics and Fax: 319-335-3017 +> Actuarial Science +> 241 Schaeffer Hall email: luke-tierney at uiowa.edu +> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu + + + +-- +Konrad Rudolph // @klmr + + [[alternative HTML version deleted]] + + +From kev|n@r@coombe@ @end|ng |rom gm@||@com Wed May 1 22:56:31 2024 +From: kev|n@r@coombe@ @end|ng |rom gm@||@com (Kevin R. Coombes) +Date: Wed, 1 May 2024 16:56:31 -0400 +Subject: [R-pkg-devel] re-exporting plot method? +In-Reply-To: +References: <422b1f93-c779-40fd-a492-c6656960b354@gmail.com> + +Message-ID: <46021147-bd1f-4955-9bf9-657a22b7f029@gmail.com> + +Hi Simon, + +Thanks for the detailed answer. I had considered all those +possibilities, and was hoping that I had just missed something obvious. + +I have been using S4 classes in my own packages for quite a while. But +here, I didn't see any need to create my own class. Now, I may make my +own, which presents a more abstract "graph" that can have realizations +both as 'igraph' or "graphNEL' - 'Rargaph'. I'll have to think about, +but that seems like the only reliable way to prevent putting al of +Rgraphviz into the user's namespace. + +Oh, and CRAN doesn't complain about importing Rgraphviz, since +BioConductor is one of the "standard mainstream" repositories. + +Best, + ? Kevin + +On 4/30/2024 11:46 PM, Simon Urbanek wrote: +> Kevin, +> +> welcome to the S4 world! ;) There is really no good solution since S4 only works at all if you attach the package since it relies on replacing the base S3 generic with its own - so the question remains what are your options to do it. +> +> The most obvious is to simply add Depends: Rgraphviz which makes sure that any generics required are attached so your package doesn't need to worry. This is the most reliable in a way as you are not limiting the functionality to methods you know about. The side-effect, though, (beside exposing functions the user may not care about) is that such package cannot be on CRAN since Rgraphics is not on CRAN (that said, you mentioned you are already importing then you seem not to worry about that). +> +> The next option is to simply ignore Rgraphviz and instead add setGeneric("plot") to your package and add methods to Depends and importFrom(methods, setGeneric) + exportMethods(plot) to the namespace. This allows you to forget about any dependencies - you are just creating the S4 generic from base::plot to make the dispatch work. This is the most light-weight solution as you only cherry-pick methods you need and there are no dependencies other than "methods". However, it is limited to just the functions you care about. +> +> Finally, you could re-export the S4 plot generic from Rgraphviz, but I'd say that is the least sensible option, since it doesn't have any benefit over doing it yourself and only adds a hard dependency for no good reason. Also copying functions from another package opens up a can of worms with versions etc. - even if the risk is likely minimal. +> +> Just for completeness - a really sneaky way would be to export an S3 plot method from your package - it would be only called in the case where the plot generic has not been replaced yet, so you could "fix" things on the fly by calling the generic from Rgraphviz, but that sounds a little hacky even for my taste ;). +> +> Cheers, +> Simon +> +> +> +>> On 1/05/2024, at 6:03 AM, Kevin R. Coombes wrote: +>> +>> Hi, +>> +>> I am working on a new package that primarily makes use of "igraph" representations of certain mathematical graphs, in order to apply lots of the comp sci algorithms already implemented in that package. For display purposes, my "igraph" objects already include information that defines node shapes and colors and edge styles and colors. But, I believe that the "graph" - "Rgraphviz" - "graphNEL" set of tools will produce better plots of the graphs. +>> +>> So, I wrote my own "as.graphNEL" function that converts the "igraph" objects I want to use into graphNEL (or maybe into "Ragraph") format in order to be able to use their graph layout and rendering routines. This function is smart enough to translate the node and edge attributes from igraph into something that works correctly when plotted using the tools in Rgraphviz. (My DESCRIPTION and NAMESPACE files already import the set of functions from Rgraphviz necessary to make this happen.) +>> +>> In principle, I'd like the eventual user to simply do something like +>> +>> library("KevinsNewPackage") +>> IG <- makeIgraphFromFile(sourcefile) +>> GN <- as.graphNEL(IG) +>> plot(GN) +>> +>> The first three lines work fine, but the "plot" function only works if the user also explicitly includes the line +>> +>> library("Rgraphviz") +>> +>> I suspect that there is a way with imports and exports in the NAMESPACE to make this work without having to remind the user to load the other package. But (in part because the plot function in Rgraphviz is actually an S4 method, which I don't need to alter in any way), I'm not sure exactly what needs to be imported or exported. +>> +>> Helpful suggestion would be greatly appreciated. +>> +>> Best, +>> Kevin +>> +>> ______________________________________________ +>> R-package-devel at r-project.org mailing list +>> https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> + + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Fri May 3 11:37:57 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Fri, 3 May 2024 11:37:57 +0200 +Subject: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS + Exploit +Message-ID: + +I hope this message finds you well. + +Following the recent announcement of a vulnerability related to the +RDS exploit in R +(https://hiddenlayer.com/research/r-bitrary-code-execution/). +Recent discussions on social media have raised concerns about the +credibility of the R language. Any code, including pure R code, can +potentially be malicious if it is executed without proper scrutiny. +It is worth noting that a similar problem was reported for the Python +pickle a few years ago: +https://hiddenlayer.com/research/weaponizing-machine-learning-models-with-ransomware/#Exploiting-Serialization. + +In my opinion, not an exploit is a central problem, but if it is +introduced in any CRAN package. + +I believe we must conduct a comprehensive review of all existing CRAN +packages. Additionally, I will expect an introduction of an additional +step in the R CMD check process. It is stated that R Team is aware of +that, and the exploit is fixed in R 4.4.0, but I can not find any +clear bullet point in the NEWS file for 4.4.0 +(https://cran.r-project.org/doc/manuals/r-release/NEWS.html). + +I look forward to your thoughts and collaborating closely on this urgent review. + +KR +Maciej Nasinski +University of Warsaw + + +From |kry|ov @end|ng |rom d|@root@org Fri May 3 11:52:47 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 3 May 2024 12:52:47 +0300 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: +Message-ID: <20240503125247.55c2ef6b@arachnoid> + +Dear Maciej Nasinski, + +On Fri, 3 May 2024 11:37:57 +0200 +Maciej Nasinski wrote: + +> I believe we must conduct a comprehensive review of all existing CRAN +> packages. + +Why now? R packages are already code. You don't need poisoned RDS files +to wreak havoc using an R package. + +On the other hand, R data files contain R objects, which contain code. +You don't need exploits to smuggle code inside an R object. + +> Additionally, I will expect an introduction of an additional +> step in the R CMD check process. + +What exactly would you like this step to be? + +> It is stated that R Team is aware of +> that, and the exploit is fixed in R 4.4.0, but I can not find any +> clear bullet point in the NEWS file for 4.4.0 +> (https://cran.r-project.org/doc/manuals/r-release/NEWS.html). + +This has recently been discussed in the R-help thread: +https://stat.ethz.ch/pipermail/r-help/2024-May/479287.html + +> I look forward to your thoughts and collaborating closely on this +> urgent review. + +It may be worth teaching people that in general, R data files should be +as trusted as R code. + +It may also be worth setting aside a strict subset of the R data format +to carry data only, without any executable code [*], but it may turn +out to be much less useful than it sounds. For example, you won't be +able to save many kinds of model objects using this plain data format, +which makes it unrealistic to require plain data only inside data files +in CRAN packages. + +An independent review of the whole >20000 packages on CRAN for +malicious behaviour is a noble endeavour, but it will require people +and funding. Perhaps you could try to apply for an R Consortium +infrastructure grant to do that. + +-- +Best regards, +Ivan + +[*] https://aitap.github.io/2024/05/02/unserialize.html#subset + + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Fri May 3 12:04:27 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Fri, 3 May 2024 12:04:27 +0200 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: <20240503125247.55c2ef6b@arachnoid> +References: <20240503125247.55c2ef6b@arachnoid> +Message-ID: + +Dear Ivan, + +Thank you for such a quick response. +?It may be worth teaching people that, in general, R data files should be +as trusted as R code.? I totally agree and that why I wrote that any code can be dangerous if run without proper scrutiny. +A few linkedin post generated most probably by Chat GPT (a lot of icons in them) make a lot of harm lastly. For sure I will try to make a post in my community and will remind that any code can be dangerous. + +BTW. we can limit the possible scan with crandb downloads stats to only those which have more than x downloads a day:) I image it will be a demanding project. + +KR +Maciej Nasinski +University of Warsaw + +> On 3 May 2024, at 11:52, Ivan Krylov wrote: +> +> It may be worth teaching people that in general, R data files should be +> as trusted as R code. + + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Fri May 3 12:22:55 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Fri, 3 May 2024 12:22:55 +0200 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: +Message-ID: <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> + +Dear Ivan, + +Your blog post is fantastic and I already start to promote it on LinkedIn with full credit to you. + +KR +Maciej Nasinski +University of Warsaw + +> On 3 May 2024, at 12:04, Maciej Nasinski wrote: +> +> ?Dear Ivan, +> +> Thank you for such a quick response. +> ?It may be worth teaching people that, in general, R data files should be +> as trusted as R code.? I totally agree and that why I wrote that any code can be dangerous if run without proper scrutiny. +> A few linkedin post generated most probably by Chat GPT (a lot of icons in them) make a lot of harm lastly. For sure I will try to make a post in my community and will remind that any code can be dangerous. +> +> BTW. we can limit the possible scan with crandb downloads stats to only those which have more than x downloads a day:) I image it will be a demanding project. +> +> KR +> Maciej Nasinski +> University of Warsaw +> +>> On 3 May 2024, at 11:52, Ivan Krylov wrote: +>> +>> It may be worth teaching people that in general, R data files should be +>> as trusted as R code. + + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Fri May 3 18:17:52 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Fri, 3 May 2024 18:17:52 +0200 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> +References: + <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> +Message-ID: + +Hey All, + +Once more, Ivan, thank you for your great blog post. +I found the https://github.com/hrbrmstr/rdaradar solution and ran it on the +100 most downloaded R packages. +Happily, all data/inst rda files are safe/non-exposed to RDS exploit (using +the linked solution). +Please access my fork for the results +https://github.com/Polkas/rdaradar/blob/main/cran_top_results.txt and the +run https://github.com/Polkas/rdaradar/blob/main/iter_all.R + +It will be great to run it on all CRAN packages, but I imagine we should be +sure that the check is decent enough to not overload the servers without a +need. + +KR +Maciej Nasinski +University of Warsaw + +On Fri, 3 May 2024 at 12:23, Maciej Nasinski +wrote: + +> Dear Ivan, +> +> Your blog post is fantastic and I already start to promote it on LinkedIn +> with full credit to you. +> +> KR +> Maciej Nasinski +> University of Warsaw +> +> > On 3 May 2024, at 12:04, Maciej Nasinski +> wrote: +> > +> > ?Dear Ivan, +> > +> > Thank you for such a quick response. +> > ?It may be worth teaching people that, in general, R data files should be +> > as trusted as R code.? I totally agree and that why I wrote that any +> code can be dangerous if run without proper scrutiny. +> > A few linkedin post generated most probably by Chat GPT (a lot of icons +> in them) make a lot of harm lastly. For sure I will try to make a post in +> my community and will remind that any code can be dangerous. +> > +> > BTW. we can limit the possible scan with crandb downloads stats to only +> those which have more than x downloads a day:) I image it will be a +> demanding project. +> > +> > KR +> > Maciej Nasinski +> > University of Warsaw +> > +> >> On 3 May 2024, at 11:52, Ivan Krylov wrote: +> >> +> >> It may be worth teaching people that in general, R data files should be +> >> as trusted as R code. +> + + [[alternative HTML version deleted]] + + +From j@h@d||e|d @end|ng |rom ed@@c@uk Fri May 3 17:17:13 2024 +From: j@h@d||e|d @end|ng |rom ed@@c@uk (Jarrod Hadfield) +Date: Fri, 3 May 2024 15:17:13 +0000 +Subject: [R-pkg-devel] Error handling in C code +Message-ID: + +Hi, + +I have an R library with C code in it. It has failed the CRAN checks for Debian. The problem is with the error function being undefined. Section 6.2 of the Writing R extensions (see below) suggests error handling can be handled by error and the appropriate header file is included in R.h, but this seems not to be the case? + +Any help would be appreciated! + +Thanks, + +Jarrod + +6.2 Error signaling + +The basic error signaling routines are the equivalents of stop and warning in R code, and use the same interface. + +void error(const char * format, ...); +void warning(const char * format, ...); +void errorcall(SEXP call, const char * format, ...); +void warningcall(SEXP call, const char * format, ...); +void warningcall_immediate(SEXP call, const char * format, ...); + +These have the same call sequences as calls to printf, but in the simplest case can be called with a single character string argument giving the error message. (Don?t do this if the string contains ?%? or might otherwise be interpreted as a format.) + +These are defined in header R_ext/Error.h included by R.h. +The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. + + [[alternative HTML version deleted]] + + +From murdoch@dunc@n @end|ng |rom gm@||@com Fri May 3 20:12:53 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Fri, 3 May 2024 14:12:53 -0400 +Subject: [R-pkg-devel] Error handling in C code +In-Reply-To: +References: +Message-ID: <89a82bc6-814b-4486-b76c-bbb1cbc79f94@gmail.com> + +Most functions in R have a prefix on their name, with aliases defined so +you can use the function without the prefix. But you can turn off the +aliasing, in which case you need the true name. I think for all of the +functions you list the prefix is "Rf_", so they are "Rf_error", etc. + +Perhaps you turned off the aliasing? + +Duncan Murdoch + +On 03/05/2024 11:17 a.m., Jarrod Hadfield wrote: +> Hi, +> +> I have an R library with C code in it. It has failed the CRAN checks for Debian. The problem is with the error function being undefined. Section 6.2 of the Writing R extensions (see below) suggests error handling can be handled by error and the appropriate header file is included in R.h, but this seems not to be the case? +> +> Any help would be appreciated! +> +> Thanks, +> +> Jarrod +> +> 6.2 Error signaling +> +> The basic error signaling routines are the equivalents of stop and warning in R code, and use the same interface. +> +> void error(const char * format, ...); +> void warning(const char * format, ...); +> void errorcall(SEXP call, const char * format, ...); +> void warningcall(SEXP call, const char * format, ...); +> void warningcall_immediate(SEXP call, const char * format, ...); +> +> These have the same call sequences as calls to printf, but in the simplest case can be called with a single character string argument giving the error message. (Don?t do this if the string contains ?%? or might otherwise be interpreted as a format.) +> +> These are defined in header R_ext/Error.h included by R.h. +> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. +> +> [[alternative HTML version deleted]] +> +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From |kry|ov @end|ng |rom d|@root@org Fri May 3 22:57:09 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 3 May 2024 23:57:09 +0300 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> + +Message-ID: <20240503235709.564e2930@Tarkus> + +On Fri, 3 May 2024 18:17:52 +0200 +Maciej Nasinski wrote: + +> I found the https://github.com/hrbrmstr/rdaradar solution and ran it +> on the 100 most downloaded R packages. +> Happily, all data/inst rda files are safe/non-exposed to RDS exploit +> (using the linked solution). + +This is a bit useful - knowing that there are no obvious exploits in +the 100 most downloaded CRAN packages is better that not knowing that - +but it is important to keep the big picture in mind. Bob himself said +that the script is "super basic". Currently, it only checks whether an +*.rda file, when loaded in the global environment, would shadow certain +important functions. This is not an attack a package author would +perform; this is something one would send directly to the victim. + +In order to defeat an attacker, you must think like an attacker. + +Here's someone jokingly describing how they would trojan the world's +online shop checkout systems if they wanted to commit financial crimes: +https://archive.ph/FCdBu +(With kindness and pull requests.) + +Here's someone spending two years to plant a fake maintainer with a +backdoor in a key free software project: +https://lwn.net/Articles/967192/ +(The backdoor was assembled from obfuscated "test files for the +decompressor".) + +Here's the 2015 Underhanded C Contest, where people competed in writing +the most harmless-looking code that would instead do something +nefarious: http://www.underhanded-c.org/ + +On the one hand, hiding the bad functions in a data file (which is +compressed and binary) instead of the R files (which are plain text and +indexed everywhere) would be the obvious first step, so it may be +useful to flag data files with functions in them for human review. + +On the other hand, an evil package author has so many tools at their +disposal that they may not need this one in particular. There are CRAN +packages with tens of megabytes of compiled code inside. Sneaking a +little extra something in a file starting with "// This is generated +grammar parser. Do not edit!" followed by an impenetrable wall of C +could be easier and stay undetected for longer. How many packages use +Java? You don't even have to ship the Java source together with an R +package, so one of your *.jars could have a poisoned dependency with +nobody being the wiser. + +Attackers are very cunning, and we don't even know what exactly we are +looking for. We can automate some of it, but the kind of code review +that will spot an evil function tucked 50 layers inside a giant +auxiliary data object is a lot of effort, hours to days per package. + +> It will be great to run it on all CRAN packages, but I imagine we +> should be sure that the check is decent enough to not overload the +> servers without a need. + +This probably counts as creating an unofficial CRAN mirror: +https://cran.r-project.org/mirror-howto.html + +(I remember someone sending too many requests to download packages one +my one and losing access from a university address to CRAN as a result.) + +You'll need 12.7 Gb for the current versions of the packages or >400 Gb +for the whole archive. + +-- +Best regards, +Ivan + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Fri May 3 23:24:33 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Fri, 3 May 2024 17:24:33 -0400 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: <20240503235709.564e2930@Tarkus> +References: + <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> + + <20240503235709.564e2930@Tarkus> +Message-ID: + +I agree with Ivan here. And more generally, R is a fully featured +programming language. You don't need just this one "exploit" (though, it +really does feel like a feature to some degree lol!) to be a bad guy with +R. + +You can link to a pre-compiled binary (like my team makes for an R package +that contains proprietary code +https://github.com/R-ArcGIS/r-bridge/tree/master/libs/x64) and call +completely compiled function that have bad side effects. You can initialize +a logger in `.onLoad()` or have a function that sends your data to someone +using httr quietly while doing something actually useful. + +There are also fairly widely used R packages that exist on GitHub/Lab or +r-universe or elsewhere. + +You'd be taking on a sisyphean task trying to route out all the evil code +from the R world. +There's also likely little to none of it (shouts out to CRAN maintainers +for being really good at what they do even if it does grind my gears +sometimes ??) + + + +On Fri, May 3, 2024 at 4:57?PM Ivan Krylov via R-package-devel < +r-package-devel at r-project.org> wrote: + +> On Fri, 3 May 2024 18:17:52 +0200 +> Maciej Nasinski wrote: +> +> > I found the https://github.com/hrbrmstr/rdaradar solution and ran it +> > on the 100 most downloaded R packages. +> > Happily, all data/inst rda files are safe/non-exposed to RDS exploit +> > (using the linked solution). +> +> This is a bit useful - knowing that there are no obvious exploits in +> the 100 most downloaded CRAN packages is better that not knowing that - +> but it is important to keep the big picture in mind. Bob himself said +> that the script is "super basic". Currently, it only checks whether an +> *.rda file, when loaded in the global environment, would shadow certain +> important functions. This is not an attack a package author would +> perform; this is something one would send directly to the victim. +> +> In order to defeat an attacker, you must think like an attacker. +> +> Here's someone jokingly describing how they would trojan the world's +> online shop checkout systems if they wanted to commit financial crimes: +> https://archive.ph/FCdBu +> (With kindness and pull requests.) +> +> Here's someone spending two years to plant a fake maintainer with a +> backdoor in a key free software project: +> https://lwn.net/Articles/967192/ +> (The backdoor was assembled from obfuscated "test files for the +> decompressor".) +> +> Here's the 2015 Underhanded C Contest, where people competed in writing +> the most harmless-looking code that would instead do something +> nefarious: http://www.underhanded-c.org/ +> +> On the one hand, hiding the bad functions in a data file (which is +> compressed and binary) instead of the R files (which are plain text and +> indexed everywhere) would be the obvious first step, so it may be +> useful to flag data files with functions in them for human review. +> +> On the other hand, an evil package author has so many tools at their +> disposal that they may not need this one in particular. There are CRAN +> packages with tens of megabytes of compiled code inside. Sneaking a +> little extra something in a file starting with "// This is generated +> grammar parser. Do not edit!" followed by an impenetrable wall of C +> could be easier and stay undetected for longer. How many packages use +> Java? You don't even have to ship the Java source together with an R +> package, so one of your *.jars could have a poisoned dependency with +> nobody being the wiser. +> +> Attackers are very cunning, and we don't even know what exactly we are +> looking for. We can automate some of it, but the kind of code review +> that will spot an evil function tucked 50 layers inside a giant +> auxiliary data object is a lot of effort, hours to days per package. +> +> > It will be great to run it on all CRAN packages, but I imagine we +> > should be sure that the check is decent enough to not overload the +> > servers without a need. +> +> This probably counts as creating an unofficial CRAN mirror: +> https://cran.r-project.org/mirror-howto.html +> +> (I remember someone sending too many requests to download packages one +> my one and losing access from a university address to CRAN as a result.) +> +> You'll need 12.7 Gb for the current versions of the packages or >400 Gb +> for the whole archive. +> +> -- +> Best regards, +> Ivan +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From @vi@e@gross m@iii@g oii gm@ii@com Sat May 4 01:04:43 2024 +From: @vi@e@gross m@iii@g oii gm@ii@com (@vi@e@gross m@iii@g oii gm@ii@com) +Date: Fri, 3 May 2024 19:04:43 -0400 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <47868CD6-5AE5-4FF4-BC4B-B93D8B87BBE4@gmail.com> + + <20240503235709.564e2930@Tarkus> + +Message-ID: <005f01da9dae$49725170$dc56f450$@gmail.com> + +Yes, this may have hit the news as a problem but any code anywhere can be a security issue. + +If you want to read lots of R code and also the code for add-ins from libraries and compile everything from scratch with a trusted set of tools, and refuse to open any of the files being discussed and so on, and only use packages on your machine and already examined, sure. You can be a tad safer. + +But as shown for years, it is quite possible to obfuscate the code in many languages to the point where you may not easily figure out what the code will do! And most people cannot and will not read source code as at some point it is easier to do what they want another way. + +What is sort of new here is a level of indirection that happens because of the way you can store things in a file and read them in so they execute. But is it all that much more dangerous than regular R code that opens up some remote file or reads records from a database and then does an eval() on the random text? + +Having said that, this is a bit like the Virus Detection industry. You may scan files in endless ways to recognize a KNOWN signature and then find lots of false positives too. Obviously places like CRAN might be able to do a scan on files in packages, or maybe you could open files with a wrapper that checks the innards for known dangers. But unless this becomes a widely used exploitation before it is fixed, ... + + +-----Original Message----- +From: R-package-devel On Behalf Of Josiah Parry +Sent: Friday, May 3, 2024 5:25 PM +To: Ivan Krylov +Cc: r-package-devel at r-project.org +Subject: Re: [R-pkg-devel] Urgent Review of R Packages in Light of Recent RDS Exploit + +I agree with Ivan here. And more generally, R is a fully featured +programming language. You don't need just this one "exploit" (though, it +really does feel like a feature to some degree lol!) to be a bad guy with +R. + +You can link to a pre-compiled binary (like my team makes for an R package +that contains proprietary code +https://github.com/R-ArcGIS/r-bridge/tree/master/libs/x64) and call +completely compiled function that have bad side effects. You can initialize +a logger in `.onLoad()` or have a function that sends your data to someone +using httr quietly while doing something actually useful. + +There are also fairly widely used R packages that exist on GitHub/Lab or +r-universe or elsewhere. + +You'd be taking on a sisyphean task trying to route out all the evil code +from the R world. +There's also likely little to none of it (shouts out to CRAN maintainers +for being really good at what they do even if it does grind my gears +sometimes ??) + + + +On Fri, May 3, 2024 at 4:57?PM Ivan Krylov via R-package-devel < +r-package-devel at r-project.org> wrote: + +> On Fri, 3 May 2024 18:17:52 +0200 +> Maciej Nasinski wrote: +> +> > I found the https://github.com/hrbrmstr/rdaradar solution and ran it +> > on the 100 most downloaded R packages. +> > Happily, all data/inst rda files are safe/non-exposed to RDS exploit +> > (using the linked solution). +> +> This is a bit useful - knowing that there are no obvious exploits in +> the 100 most downloaded CRAN packages is better that not knowing that - +> but it is important to keep the big picture in mind. Bob himself said +> that the script is "super basic". Currently, it only checks whether an +> *.rda file, when loaded in the global environment, would shadow certain +> important functions. This is not an attack a package author would +> perform; this is something one would send directly to the victim. +> +> In order to defeat an attacker, you must think like an attacker. +> +> Here's someone jokingly describing how they would trojan the world's +> online shop checkout systems if they wanted to commit financial crimes: +> https://archive.ph/FCdBu +> (With kindness and pull requests.) +> +> Here's someone spending two years to plant a fake maintainer with a +> backdoor in a key free software project: +> https://lwn.net/Articles/967192/ +> (The backdoor was assembled from obfuscated "test files for the +> decompressor".) +> +> Here's the 2015 Underhanded C Contest, where people competed in writing +> the most harmless-looking code that would instead do something +> nefarious: http://www.underhanded-c.org/ +> +> On the one hand, hiding the bad functions in a data file (which is +> compressed and binary) instead of the R files (which are plain text and +> indexed everywhere) would be the obvious first step, so it may be +> useful to flag data files with functions in them for human review. +> +> On the other hand, an evil package author has so many tools at their +> disposal that they may not need this one in particular. There are CRAN +> packages with tens of megabytes of compiled code inside. Sneaking a +> little extra something in a file starting with "// This is generated +> grammar parser. Do not edit!" followed by an impenetrable wall of C +> could be easier and stay undetected for longer. How many packages use +> Java? You don't even have to ship the Java source together with an R +> package, so one of your *.jars could have a poisoned dependency with +> nobody being the wiser. +> +> Attackers are very cunning, and we don't even know what exactly we are +> looking for. We can automate some of it, but the kind of code review +> that will spot an evil function tucked 50 layers inside a giant +> auxiliary data object is a lot of effort, hours to days per package. +> +> > It will be great to run it on all CRAN packages, but I imagine we +> > should be sure that the check is decent enough to not overload the +> > servers without a need. +> +> This probably counts as creating an unofficial CRAN mirror: +> https://cran.r-project.org/mirror-howto.html +> +> (I remember someone sending too many requests to download packages one +> my one and losing access from a university address to CRAN as a result.) +> +> You'll need 12.7 Gb for the current versions of the packages or >400 Gb +> for the whole archive. +> +> -- +> Best regards, +> Ivan +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + +______________________________________________ +R-package-devel at r-project.org mailing list +https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Sat May 4 07:17:34 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Sat, 4 May 2024 01:17:34 -0400 (EDT) +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: <20240503125247.55c2ef6b@arachnoid> +References: + <20240503125247.55c2ef6b@arachnoid> +Message-ID: + + + +On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: + +> Dear Maciej Nasinski, +> +> On Fri, 3 May 2024 11:37:57 +0200 +> Maciej Nasinski wrote: +> +>> I believe we must conduct a comprehensive review of all existing CRAN +>> packages. +> +> Why now? R packages are already code. You don't need poisoned RDS files +> to wreak havoc using an R package. +> +> On the other hand, R data files contain R objects, which contain code. +> You don't need exploits to smuggle code inside an R object. +> + +I think the confusion arises because users expect "R data files" to only +contain data, i.e. numbers, but they can contain any R object, including +functions. + +I, personally, never use them out of concern that accidentally saved +function can override some functionality and be difficult to debug. And, +of course, I never save R sessions. + +If you need to pass data it is a good idea to use some common format like +tab-separated CSV files with column names. One can also use MVL files +(RMVL package). + +best + +Vladimir Dergachev + + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Sat May 4 08:09:28 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Sat, 4 May 2024 08:09:28 +0200 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + +Message-ID: + +Thank you all for the discussion. +Then, we should promote "code awareness" and count on the CRAN Team to +continue their great work:) + +What do you think about promoting containers? +Nowadays, containers are more accessible, with GitHub codespaces being more +affordable (mostly free for students and the educational sector). +I feel containers can help a little bit in making the R work more +secure, but once more when used properly. + +KR +Maciej Nasinski +University of Warsaw + +On Sat, 4 May 2024 at 07:17, Vladimir Dergachev +wrote: + +> +> +> On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: +> +> > Dear Maciej Nasinski, +> > +> > On Fri, 3 May 2024 11:37:57 +0200 +> > Maciej Nasinski wrote: +> > +> >> I believe we must conduct a comprehensive review of all existing CRAN +> >> packages. +> > +> > Why now? R packages are already code. You don't need poisoned RDS files +> > to wreak havoc using an R package. +> > +> > On the other hand, R data files contain R objects, which contain code. +> > You don't need exploits to smuggle code inside an R object. +> > +> +> I think the confusion arises because users expect "R data files" to only +> contain data, i.e. numbers, but they can contain any R object, including +> functions. +> +> I, personally, never use them out of concern that accidentally saved +> function can override some functionality and be difficult to debug. And, +> of course, I never save R sessions. +> +> If you need to pass data it is a good idea to use some common format like +> tab-separated CSV files with column names. One can also use MVL files +> (RMVL package). +> +> best +> +> Vladimir Dergachev +> +> + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Sat May 4 11:49:51 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Sat, 4 May 2024 12:49:51 +0300 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + + +Message-ID: <20240504124951.3b5e7df4@Tarkus> + +On Sat, 4 May 2024 08:09:28 +0200 +Maciej Nasinski wrote: + +> What do you think about promoting containers? + +Containers have an attack surface too, have user experience problems +(how's Docker on Windows?) and may bring in more third-party code than +what you're trying to protect against (whole operating system images!). +Even Firejail and Bubblewrap, containers specifically designed to +sandbox untrusted code, have bugs in their setup or implementation +every now and then. + +Still, you are welcome to run third-party code in a virtual machine or +a container. It may be not everyone's favourite trade-off, but is a net +increase in security over running untrusted code directly. Feel free to +search for a point on the Pareto optimal line between security and +convenience that you'll be comfortable with: https://xkcd.com/2044/ + +> Nowadays, containers are more accessible, with GitHub codespaces +> being more affordable (mostly free for students and the educational +> sector). + +The GitHub-isation of the development process is kind of a +vulnerability too, or at the very least has a cost. I'm a few +handshakes away from several people who have been disappeared from +GitHub and couldn't get their accounts back. Microsoft is too big to +have real tech support [*], so once you fall foul of their AI +moderation systems, you'll have to be a Hacker News celebrity to +attract attention of a human on the inside. + +I've got an ageing ThinkPad that I cannot afford to replace. It can +process all the data I've been gathering during my PhD and then some, +least squares, inverse problems, you name it, all while playing music +and having Quake I open. But the moment I try to launch Codespaces, it +downloads more bytes of JavaScript than the whole Quake I installation +takes in size, and then the browser overheats the laptop. + +Maybe programming other people's computers in the browser is the +future, but then you need a fancy laptop and maybe a friend in +Microsoft just to be admitted into that future. A solution for some, +but not for all. + +-- +Best regards, +Ivan + +[*] https://danluu.com/diseconomies-scale/ + + +From @bew|ck @end|ng |rom c|em@on@edu Sat May 4 17:53:25 2024 +From: @bew|ck @end|ng |rom c|em@on@edu (Sharon Bewick) +Date: Sat, 4 May 2024 15:53:25 +0000 +Subject: [R-pkg-devel] Trouble with dependencies on phyloseq and microViz +Message-ID: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> + +I?m having trouble with: +r-oldrel-macos-arm64 +and +r-oldrel-macos-x86_64 + +flagging an error because I have a dependency on phyloseq, which is available through GitHub but not on the CRAN site. I have a similar problem with microViz, however I?ve managed to make it suggested, rather than required. There is no way to get around the phyloseq requirement. How do I fix this problem so that I can upload my package to the CRAN website? I feel like I had this problem with microViz in the past, but now it?s coming up with phylseq too, and I can?t remove that dependency. + +Thanks! +Sharon + +From murdoch@dunc@n @end|ng |rom gm@||@com Sat May 4 18:06:14 2024 +From: murdoch@dunc@n @end|ng |rom gm@||@com (Duncan Murdoch) +Date: Sat, 4 May 2024 12:06:14 -0400 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> +Message-ID: <7d0fbfd9-db95-4e13-add9-a7bd79bce7bb@gmail.com> + +On 04/05/2024 11:53 a.m., Sharon Bewick wrote: +> I?m having trouble with: +> r-oldrel-macos-arm64 +> and +> r-oldrel-macos-x86_64 +> +> flagging an error because I have a dependency on phyloseq, which is available through GitHub but not on the CRAN site. I have a similar problem with microViz, however I?ve managed to make it suggested, rather than required. There is no way to get around the phyloseq requirement. How do I fix this problem so that I can upload my package to the CRAN website? I feel like I had this problem with microViz in the past, but now it?s coming up with phylseq too, and I can?t remove that dependency. +> + +phyloseq is a Bioconductor package. It appears to be available from +BioConductor, so it doesn't matter that it's not on CRAN. + +Have you tried submitting your package to CRAN? If so, could you show +us the error you received? + +Duncan Murdoch + + +From |kry|ov @end|ng |rom d|@root@org Sat May 4 18:32:10 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Sat, 4 May 2024 19:32:10 +0300 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> +Message-ID: <20240504193210.0332d714@Tarkus> + +? Sat, 4 May 2024 15:53:25 +0000 +Sharon Bewick ?????: + +> I have a dependency on phyloseq, which is available through GitHub +> but not on the CRAN site. I have a similar problem with microViz, +> however I?ve managed to make it suggested, rather than required. +> There is no way to get around the phyloseq requirement. How do I fix +> this problem so that I can upload my package to the CRAN website? + +Did a human reviewer tell you to get rid of the dependencies? There is +at least 444 packages on CRAN with strong dependencies on Bioconductor +packages, so your phyloseq dependency should work. In fact, 14 of them +depend on phyloseq. + +What you need is an Additional_repositories field in your DESCRIPTION +specifying the source package repository where microViz could be +installed from. I think that + +Additional_repositories: https://david-barnett.r-universe.dev + +...should work. + +Besides that, you'll need to increment the version and list the *.Rproj +file in .Rbuildignore: +https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.1_20240504_173331/Debian/00check.log + +-- +Best regards, +Ivan + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Sat May 4 18:53:07 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Sat, 4 May 2024 12:53:07 -0400 (EDT) +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + + +Message-ID: + + + +On Sat, 4 May 2024, Maciej Nasinski wrote: + +> Thank you all for the discussion.Then, we should promote "code awareness" and count on the CRAN Team to continue their great work:) +> +> What do you think about promoting containers? +> Nowadays, containers are more accessible, with GitHub codespaces being more affordable (mostly free for students and the educational sector). +> I feel containers can help a little bit in making the R work more secure,?but once more when used properly. + +I think it is not a good idea to focus on one use case. Some people will +find containers more convenient some don't. + +If you want security, I am sure containers are not the right approach - +get a separate physical computer instead. + +>From a convenience point of view containers are only ok as long as you +don't need to interface with outside software, then it gets tricky as the +security keeping things containerized starts interfering with getting work +done. (Prime example: firefox snap on ubuntu) + +One situation where containers can be helpful is distribution of +commercial applications. Containers allow you to freeze library versions, +so your app can still run with old C library or a specific version of +Python. You can then _hope_ that containers will have fewer compatibility +issues, or at least you can sell containers to your management on this +idea. + +But this is not really a good thing for an open source project like R. + +best + +Vladimir Dergachev + +> +> KR +> Maciej Nasinski +> University of Warsaw +> +> On Sat, 4 May 2024 at 07:17, Vladimir Dergachev wrote: +> +> +> On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: +> +> > Dear Maciej Nasinski, +> > +> > On Fri, 3 May 2024 11:37:57 +0200 +> > Maciej Nasinski wrote: +> > +> >> I believe we must conduct a comprehensive review of all existing CRAN +> >> packages. +> > +> > Why now? R packages are already code. You don't need poisoned RDS files +> > to wreak havoc using an R package. +> > +> > On the other hand, R data files contain R objects, which contain code. +> > You don't need exploits to smuggle code inside an R object. +> > +> +> I think the confusion arises because users expect "R data files" to only +> contain data, i.e. numbers, but they can contain any R object, including +> functions. +> +> I, personally, never use them out of concern that accidentally saved +> function can override some functionality and be difficult to debug. And, +> of course, I never save R sessions. +> +> If you need to pass data it is a good idea to use some common format like +> tab-separated CSV files with column names. One can also use MVL files +> (RMVL package). +> +> best +> +> Vladimir Dergachev +> +> +> + +From n@@|n@k|@m@c|ej @end|ng |rom gm@||@com Sat May 4 19:43:58 2024 +From: n@@|n@k|@m@c|ej @end|ng |rom gm@||@com (Maciej Nasinski) +Date: Sat, 4 May 2024 19:43:58 +0200 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + + + +Message-ID: + +Hey Vladimir, + +Thank you for your answer. +GitHub codespaces are "a separate computer" and are free for students and +the educational sector. +The GitHub codespaces are a cloud service that can be created anytime, with +a specific setup behind it (Dockerfile, settings.json, renv.lock, ...). +The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB +Memory). +You can destroy and recreate it anytime you want to. +You run GitHub codespaces from a web browser, but as Ivan stated, you may +need a decent computer to handle them, even if all calculations are done on +the cloud. +I use GitHub codespaces for all my University projects with my friends. It +is great that I do not have to explain many things nowadays to older stuff +as many things are automatic on GitHub codespaces. + +KR +Maciej Nasinski +University of Warsaw + +On Sat, 4 May 2024 at 18:53, Vladimir Dergachev +wrote: + +> +> +> On Sat, 4 May 2024, Maciej Nasinski wrote: +> +> > Thank you all for the discussion.Then, we should promote "code +> awareness" and count on the CRAN Team to continue their great work:) +> > +> > What do you think about promoting containers? +> > Nowadays, containers are more accessible, with GitHub codespaces being +> more affordable (mostly free for students and the educational sector). +> > I feel containers can help a little bit in making the R work more +> secure, but once more when used properly. +> +> I think it is not a good idea to focus on one use case. Some people will +> find containers more convenient some don't. +> +> If you want security, I am sure containers are not the right approach - +> get a separate physical computer instead. +> +> From a convenience point of view containers are only ok as long as you +> don't need to interface with outside software, then it gets tricky as the +> security keeping things containerized starts interfering with getting work +> done. (Prime example: firefox snap on ubuntu) +> +> One situation where containers can be helpful is distribution of +> commercial applications. Containers allow you to freeze library versions, +> so your app can still run with old C library or a specific version of +> Python. You can then _hope_ that containers will have fewer compatibility +> issues, or at least you can sell containers to your management on this +> idea. +> +> But this is not really a good thing for an open source project like R. +> +> best +> +> Vladimir Dergachev +> +> > +> > KR +> > Maciej Nasinski +> > University of Warsaw +> > +> > On Sat, 4 May 2024 at 07:17, Vladimir Dergachev +> wrote: +> > +> > +> > On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: +> > +> > > Dear Maciej Nasinski, +> > > +> > > On Fri, 3 May 2024 11:37:57 +0200 +> > > Maciej Nasinski wrote: +> > > +> > >> I believe we must conduct a comprehensive review of all +> existing CRAN +> > >> packages. +> > > +> > > Why now? R packages are already code. You don't need poisoned +> RDS files +> > > to wreak havoc using an R package. +> > > +> > > On the other hand, R data files contain R objects, which contain +> code. +> > > You don't need exploits to smuggle code inside an R object. +> > > +> > +> > I think the confusion arises because users expect "R data files" +> to only +> > contain data, i.e. numbers, but they can contain any R object, +> including +> > functions. +> > +> > I, personally, never use them out of concern that accidentally +> saved +> > function can override some functionality and be difficult to +> debug. And, +> > of course, I never save R sessions. +> > +> > If you need to pass data it is a good idea to use some common +> format like +> > tab-separated CSV files with column names. One can also use MVL +> files +> > (RMVL package). +> > +> > best +> > +> > Vladimir Dergachev +> > +> > +> > + + [[alternative HTML version deleted]] + + +From bbo|ker @end|ng |rom gm@||@com Sat May 4 20:03:42 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Sat, 4 May 2024 14:03:42 -0400 +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + + + + +Message-ID: <0a7d3fe4-6902-4e4c-8c75-7e5d9fc7caaf@gmail.com> + + This is true, and useful. + + Many old-school R users are nervous about coming to rely on tools +that are controlled by a company that may rescind that availability in +the future, or may possibly use your code in ways you don't want (I have +not gone all the way through +https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement +...) + + For example, Travis was great for CI for a while then pulled the +plug on free use for public repos, then everyone jumped to GitHub +actions ...; Microsoft Open R and MRAN were around for a while and then +weren't ... + + That doesn't mean one should necessarily avoid these tools; it just +explains why some people do. + +On 2024-05-04 1:43 p.m., Maciej Nasinski wrote: +> Hey Vladimir, +> +> Thank you for your answer. +> GitHub codespaces are "a separate computer" and are free for students and +> the educational sector. +> The GitHub codespaces are a cloud service that can be created anytime, with +> a specific setup behind it (Dockerfile, settings.json, renv.lock, ...). +> The machines GitHub codespaces offer are quite decent (4core 16GB RAM 32GB +> Memory). +> You can destroy and recreate it anytime you want to. +> You run GitHub codespaces from a web browser, but as Ivan stated, you may +> need a decent computer to handle them, even if all calculations are done on +> the cloud. +> I use GitHub codespaces for all my University projects with my friends. It +> is great that I do not have to explain many things nowadays to older stuff +> as many things are automatic on GitHub codespaces. +> +> KR +> Maciej Nasinski +> University of Warsaw +> +> On Sat, 4 May 2024 at 18:53, Vladimir Dergachev +> wrote: +> +>> +>> +>> On Sat, 4 May 2024, Maciej Nasinski wrote: +>> +>>> Thank you all for the discussion.Then, we should promote "code +>> awareness" and count on the CRAN Team to continue their great work:) +>>> +>>> What do you think about promoting containers? +>>> Nowadays, containers are more accessible, with GitHub codespaces being +>> more affordable (mostly free for students and the educational sector). +>>> I feel containers can help a little bit in making the R work more +>> secure, but once more when used properly. +>> +>> I think it is not a good idea to focus on one use case. Some people will +>> find containers more convenient some don't. +>> +>> If you want security, I am sure containers are not the right approach - +>> get a separate physical computer instead. +>> +>> From a convenience point of view containers are only ok as long as you +>> don't need to interface with outside software, then it gets tricky as the +>> security keeping things containerized starts interfering with getting work +>> done. (Prime example: firefox snap on ubuntu) +>> +>> One situation where containers can be helpful is distribution of +>> commercial applications. Containers allow you to freeze library versions, +>> so your app can still run with old C library or a specific version of +>> Python. You can then _hope_ that containers will have fewer compatibility +>> issues, or at least you can sell containers to your management on this +>> idea. +>> +>> But this is not really a good thing for an open source project like R. +>> +>> best +>> +>> Vladimir Dergachev +>> +>>> +>>> KR +>>> Maciej Nasinski +>>> University of Warsaw +>>> +>>> On Sat, 4 May 2024 at 07:17, Vladimir Dergachev +>> wrote: +>>> +>>> +>>> On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: +>>> +>>> > Dear Maciej Nasinski, +>>> > +>>> > On Fri, 3 May 2024 11:37:57 +0200 +>>> > Maciej Nasinski wrote: +>>> > +>>> >> I believe we must conduct a comprehensive review of all +>> existing CRAN +>>> >> packages. +>>> > +>>> > Why now? R packages are already code. You don't need poisoned +>> RDS files +>>> > to wreak havoc using an R package. +>>> > +>>> > On the other hand, R data files contain R objects, which contain +>> code. +>>> > You don't need exploits to smuggle code inside an R object. +>>> > +>>> +>>> I think the confusion arises because users expect "R data files" +>> to only +>>> contain data, i.e. numbers, but they can contain any R object, +>> including +>>> functions. +>>> +>>> I, personally, never use them out of concern that accidentally +>> saved +>>> function can override some functionality and be difficult to +>> debug. And, +>>> of course, I never save R sessions. +>>> +>>> If you need to pass data it is a good idea to use some common +>> format like +>>> tab-separated CSV files with column names. One can also use MVL +>> files +>>> (RMVL package). +>>> +>>> best +>>> +>>> Vladimir Dergachev +>>> +>>> +>>> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Sat May 4 20:08:18 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Sat, 4 May 2024 14:08:18 -0400 (EDT) +Subject: [R-pkg-devel] + Urgent Review of R Packages in Light of Recent RDS Exploit +In-Reply-To: +References: + <20240503125247.55c2ef6b@arachnoid> + + + + +Message-ID: + + + +On Sat, 4 May 2024, Maciej Nasinski wrote: + +> Hey Vladimir, +> Thank you for your answer. +> GitHub codespaces are "a separate computer" and are free for students and the educational sector. + +Hi Maciej, + + What I was suggesting is that instead of encapsulating the application +in a container that runs on the same physical hardware as other +containers, you would be more secure to use a dedicated computer for the +application. + + best + +Vladimir Dergachev + + +> The GitHub codespaces are a cloud service that can be created anytime, with a specific setup behind it (Dockerfile, settings.json, renv.lock,? ...). +> The machines GitHub codespaces offer are quite decent (4core 16GB RAM?32GB Memory).? +> You can destroy and recreate it anytime you want to. +> You run GitHub codespaces from a web browser, but as Ivan stated, you may need a decent computer to handle them, even if all calculations are done on the cloud. +> I use GitHub codespaces for all my University projects with my friends.? It is great that I do not have to explain?many things nowadays to older stuff as many things are automatic on GitHub +> codespaces. +> +> KR +> Maciej Nasinski +> University of Warsaw +> +> On Sat, 4 May 2024 at 18:53, Vladimir Dergachev wrote: +> +> +> On Sat, 4 May 2024, Maciej Nasinski wrote: +> +> > Thank you all for the discussion.Then, we should promote "code awareness" and count on the CRAN Team to continue their great work:) +> > +> > What do you think about promoting containers? +> > Nowadays, containers are more accessible, with GitHub codespaces being more affordable (mostly free for students and the educational sector). +> > I feel containers can help a little bit in making the R work more secure,?but once more when used properly. +> +> I think it is not a good idea to focus on one use case. Some people will +> find containers more convenient some don't. +> +> If you want security, I am sure containers are not the right approach - +> get a separate physical computer instead. +> +> >From a convenience point of view containers are only ok as long as you +> don't need to interface with outside software, then it gets tricky as the +> security keeping things containerized starts interfering with getting work +> done. (Prime example: firefox snap on ubuntu) +> +> One situation where containers can be helpful is distribution of +> commercial applications. Containers allow you to freeze library versions, +> so your app can still run with old C library or a specific version of +> Python. You can then _hope_ that containers will have fewer compatibility +> issues, or at least you can sell containers to your management on this +> idea. +> +> But this is not really a good thing for an open source project like R. +> +> best +> +> Vladimir Dergachev +> +> > +> > KR +> > Maciej Nasinski +> > University of Warsaw +> > +> > On Sat, 4 May 2024 at 07:17, Vladimir Dergachev wrote: +> > +> > +> >? ? ? ?On Fri, 3 May 2024, Ivan Krylov via R-package-devel wrote: +> > +> >? ? ? ?> Dear Maciej Nasinski, +> >? ? ? ?> +> >? ? ? ?> On Fri, 3 May 2024 11:37:57 +0200 +> >? ? ? ?> Maciej Nasinski wrote: +> >? ? ? ?> +> >? ? ? ?>> I believe we must conduct a comprehensive review of all existing CRAN +> >? ? ? ?>> packages. +> >? ? ? ?> +> >? ? ? ?> Why now? R packages are already code. You don't need poisoned RDS files +> >? ? ? ?> to wreak havoc using an R package. +> >? ? ? ?> +> >? ? ? ?> On the other hand, R data files contain R objects, which contain code. +> >? ? ? ?> You don't need exploits to smuggle code inside an R object. +> >? ? ? ?> +> > +> >? ? ? ?I think the confusion arises because users expect "R data files" to only +> >? ? ? ?contain data, i.e. numbers, but they can contain any R object, including +> >? ? ? ?functions. +> > +> >? ? ? ?I, personally, never use them out of concern that accidentally saved +> >? ? ? ?function can override some functionality and be difficult to debug. And, +> >? ? ? ?of course, I never save R sessions. +> > +> >? ? ? ?If you need to pass data it is a good idea to use some common format like +> >? ? ? ?tab-separated CSV files with column names. One can also use MVL files +> >? ? ? ?(RMVL package). +> > +> >? ? ? ?best +> > +> >? ? ? ?Vladimir Dergachev +> > +> > +> > +> +> +> + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Sat May 4 20:13:58 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Sat, 4 May 2024 14:13:58 -0400 (EDT) +Subject: [R-pkg-devel] SETLENGTH() +Message-ID: + + +I noticed a note on RMVL package check page for development version of R: + +Found non-API call to R: ?SETLENGTH? + +Is this something that is work-in-progress for the development version, or +has SETLENGTH() been deprecated ? What should I use instead ? + +thank you very much + +Vladimir Dergachev + +From iuke-tier@ey m@iii@g oii uiow@@edu Sun May 5 01:30:32 2024 +From: iuke-tier@ey m@iii@g oii uiow@@edu (iuke-tier@ey m@iii@g oii uiow@@edu) +Date: Sat, 4 May 2024 18:30:32 -0500 (CDT) +Subject: [R-pkg-devel] [External] SETLENGTH() +In-Reply-To: +References: +Message-ID: <7451301c-236e-a685-058e-9fa6da633659@uiowa.edu> + +On Sat, 4 May 2024, Vladimir Dergachev wrote: + +> [Some people who received this message don't often get email from +> volodya at mindspring.com. Learn why this is important at +> https://aka.ms/LearnAboutSenderIdentification ] +> +> I noticed a note on RMVL package check page for development version of R: +> +> Found non-API call to R: ?SETLENGTH? +> +> Is this something that is work-in-progress for the development version, or +> has SETLENGTH() been deprecated ? What should I use instead ? + +SETLENGTH has never been part of the API. It is not safe to use except +in a very, very limited set of circumstances. Using it in other +settings will confuse the memory manager, leading at least to +mis-calculation of memory use information and possibly to +segfaults. For most uses I have seen, copying to a new vector of the +right size is the only safe option. + +The one context where something along these lines might be OK is for +growable vectors. This concept is emphatically not in the API at this +point, and the way it is currently implemented in base is not robust +enough to become an API (even though some packages have used it). It +is possible that a proper API for this will be added; at that point +SETLENGTH will be removed from the accessible entry points on +platforms that allow this. + +So if you are getting a note about SETLENGTH, either stop using it or +be prepared to make some changes at fairly short notice. + +[Similar considerations apply to SET_TRUELENGT. In most but not all +cases using it is less dangerous, but you should still look for other +options if you want your code to continue to work.] + +Best, + +luke + +> +> thank you very much +> +> Vladimir Dergachev +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + +-- +Luke Tierney +Ralph E. Wareham Professor of Mathematical Sciences +University of Iowa Phone: 319-335-3386 +Department of Statistics and Fax: 319-335-3017 + Actuarial Science +241 Schaeffer Hall email: luke-tierney at uiowa.edu +Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Sun May 5 03:45:01 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Sat, 4 May 2024 21:45:01 -0400 (EDT) +Subject: [R-pkg-devel] [External] SETLENGTH() +In-Reply-To: <7451301c-236e-a685-058e-9fa6da633659@uiowa.edu> +References: + <7451301c-236e-a685-058e-9fa6da633659@uiowa.edu> +Message-ID: + + + +On Sat, 4 May 2024, luke-tierney at uiowa.edu wrote: + +> On Sat, 4 May 2024, Vladimir Dergachev wrote: +> +>> [Some people who received this message don't often get email from +>> volodya at mindspring.com. Learn why this is important at +>> https://aka.ms/LearnAboutSenderIdentification ] +>> +>> I noticed a note on RMVL package check page for development version of R: +>> +>> Found non-API call to R: ?SETLENGTH? +>> +>> Is this something that is work-in-progress for the development version, or +>> has SETLENGTH() been deprecated ? What should I use instead ? +> +> SETLENGTH has never been part of the API. It is not safe to use except +> in a very, very limited set of circumstances. Using it in other +> settings will confuse the memory manager, leading at least to +> mis-calculation of memory use information and possibly to +> segfaults. For most uses I have seen, copying to a new vector of the +> right size is the only safe option. +> +> The one context where something along these lines might be OK is for +> growable vectors. This concept is emphatically not in the API at this +> point, and the way it is currently implemented in base is not robust +> enough to become an API (even though some packages have used it). It +> is possible that a proper API for this will be added; at that point +> SETLENGTH will be removed from the accessible entry points on +> platforms that allow this. +> +> So if you are getting a note about SETLENGTH, either stop using it or +> be prepared to make some changes at fairly short notice. +> +> [Similar considerations apply to SET_TRUELENGT. In most but not all +> cases using it is less dangerous, but you should still look for other +> options if you want your code to continue to work.] + +Great, thank you for the explanation ! I will rewrite the code to not use +SETLENGTH(). + +My use case was to allocate a vector of some size N_max and then +repeatedly populate it with variable number of elements. Since the vector +was protected during the loop, I would have expected to save on memory +allocation calls. + +best + +Vladimir Dergachev + +> +> Best, +> +> luke +> +>> +>> thank you very much +>> +>> Vladimir Dergachev +>> ______________________________________________ +>> R-package-devel at r-project.org mailing list +>> https://stat.ethz.ch/mailman/listinfo/r-package-devel +>> +> +> -- +> Luke Tierney +> Ralph E. Wareham Professor of Mathematical Sciences +> University of Iowa Phone: 319-335-3386 +> Department of Statistics and Fax: 319-335-3017 +> Actuarial Science +> 241 Schaeffer Hall email: luke-tierney at uiowa.edu +> Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu +> + + +From @|mon@urb@nek @end|ng |rom R-project@org Mon May 6 04:37:49 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Mon, 6 May 2024 14:37:49 +1200 +Subject: [R-pkg-devel] Error handling in C code +In-Reply-To: +References: +Message-ID: <49818A23-B5E0-480B-8F6D-25BE759424A4@R-project.org> + +Jarrod, + +could you point us to the code? There is not much to go by based on your email. One thing just in general: it's always safer to not re-map function names, especially since "error" can be defined in many random other headers, so it's better to use Rf_error() instead to avoid confusions with 3rd party headers that may (re-)define the "error" macro (depending on the order you include them in). + +Cheers, +Simon + + +> On 4/05/2024, at 3:17 AM, Jarrod Hadfield wrote: +> +> Hi, +> +> I have an R library with C code in it. It has failed the CRAN checks for Debian. The problem is with the error function being undefined. Section 6.2 of the Writing R extensions (see below) suggests error handling can be handled by error and the appropriate header file is included in R.h, but this seems not to be the case? +> +> Any help would be appreciated! +> +> Thanks, +> +> Jarrod +> +> 6.2 Error signaling +> +> The basic error signaling routines are the equivalents of stop and warning in R code, and use the same interface. +> +> void error(const char * format, ...); +> void warning(const char * format, ...); +> void errorcall(SEXP call, const char * format, ...); +> void warningcall(SEXP call, const char * format, ...); +> void warningcall_immediate(SEXP call, const char * format, ...); +> +> These have the same call sequences as calls to printf, but in the simplest case can be called with a single character string argument giving the error message. (Don?t do this if the string contains ?%? or might otherwise be interpreted as a format.) +> +> These are defined in header R_ext/Error.h included by R.h. +> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From j@h@d||e|d @end|ng |rom ed@@c@uk Mon May 6 16:41:16 2024 +From: j@h@d||e|d @end|ng |rom ed@@c@uk (Jarrod Hadfield) +Date: Mon, 6 May 2024 14:41:16 +0000 +Subject: [R-pkg-devel] Error handling in C code +In-Reply-To: <49818A23-B5E0-480B-8F6D-25BE759424A4@R-project.org> +References: + <49818A23-B5E0-480B-8F6D-25BE759424A4@R-project.org> +Message-ID: + +Hi, + +Using Rf_error() rather than error() fixed the problem. Not sure why the problem was only flagged on Debian, but it seems to have been triggered by R_NO_REMAP being defined (which will be default in R 4.5.0). + +Thanks for the help. + +Jarrod + +From: Simon Urbanek +Date: Monday, 6 May 2024 at 03:38 +To: Jarrod Hadfield +Cc: r-package-devel at r-project.org +Subject: Re: [R-pkg-devel] Error handling in C code +This email was sent to you by someone outside the University. +You should only click on links or attachments if you are certain that the email is genuine and the content is safe. + +Jarrod, + +could you point us to the code? There is not much to go by based on your email. One thing just in general: it's always safer to not re-map function names, especially since "error" can be defined in many random other headers, so it's better to use Rf_error() instead to avoid confusions with 3rd party headers that may (re-)define the "error" macro (depending on the order you include them in). + +Cheers, +Simon + + +> On 4/05/2024, at 3:17 AM, Jarrod Hadfield wrote: +> +> Hi, +> +> I have an R library with C code in it. It has failed the CRAN checks for Debian. The problem is with the error function being undefined. Section 6.2 of the Writing R extensions (see below) suggests error handling can be handled by error and the appropriate header file is included in R.h, but this seems not to be the case? +> +> Any help would be appreciated! +> +> Thanks, +> +> Jarrod +> +> 6.2 Error signaling +> +> The basic error signaling routines are the equivalents of stop and warning in R code, and use the same interface. +> +> void error(const char * format, ...); +> void warning(const char * format, ...); +> void errorcall(SEXP call, const char * format, ...); +> void warningcall(SEXP call, const char * format, ...); +> void warningcall_immediate(SEXP call, const char * format, ...); +> +> These have the same call sequences as calls to printf, but in the simplest case can be called with a single character string argument giving the error message. (Don?t do this if the string contains ?%? or might otherwise be interpreted as a format.) +> +> These are defined in header R_ext/Error.h included by R.h. +> The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th? ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336. +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fr-package-devel&data=05%7C02%7C%7C27d13d00316a466dc91f08dc6d759134%7C2e9f06b016694589878910a06934dc61%7C0%7C0%7C638505599232790068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bhr0SQN0UJq4FQgEgboltgm6dH1wo5aonYTDqRvsf2g%3D&reserved=0 + + [[alternative HTML version deleted]] + + +From @|mon@urb@nek @end|ng |rom R-project@org Tue May 7 00:07:59 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Tue, 7 May 2024 10:07:59 +1200 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: <20240504193210.0332d714@Tarkus> +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> + <20240504193210.0332d714@Tarkus> +Message-ID: <7205534A-6666-4EDE-B613-68AAAFED2F2D@R-project.org> + + + +> On 5/05/2024, at 4:32 AM, Ivan Krylov via R-package-devel wrote: +> +> ? Sat, 4 May 2024 15:53:25 +0000 +> Sharon Bewick ?????: +> +>> I have a dependency on phyloseq, which is available through GitHub +>> but not on the CRAN site. I have a similar problem with microViz, +>> however I?ve managed to make it suggested, rather than required. +>> There is no way to get around the phyloseq requirement. How do I fix +>> this problem so that I can upload my package to the CRAN website? +> +> Did a human reviewer tell you to get rid of the dependencies? There is +> at least 444 packages on CRAN with strong dependencies on Bioconductor +> packages, so your phyloseq dependency should work. In fact, 14 of them +> depend on phyloseq. +> +> What you need is an Additional_repositories field in your DESCRIPTION +> specifying the source package repository where microViz could be +> installed from. I think that +> +> Additional_repositories: https://david-barnett.r-universe.dev +> +> ...should work. +> + +That doesn't work - additional repositories are not allowed on CRAN other than in very exceptional cases, because it means the package cannot be installed by users making it somewhat pointless. Bioconductor doesn't need to be flagged in Additional_repositories, but not all packages are available - only those that do no depend on the data repository. + +As for the OP, can you post the name of the package and/or the link to the errors so I can have a look? + +Cheers, +Simon + + + +> Besides that, you'll need to increment the version and list the *.Rproj +> file in .Rbuildignore: +> https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.1_20240504_173331/Debian/00check.log +> +> -- +> Best regards, +> Ivan +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +From |kry|ov @end|ng |rom d|@root@org Tue May 7 08:15:52 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Tue, 7 May 2024 09:15:52 +0300 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: <7205534A-6666-4EDE-B613-68AAAFED2F2D@R-project.org> +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> + <20240504193210.0332d714@Tarkus> + <7205534A-6666-4EDE-B613-68AAAFED2F2D@R-project.org> +Message-ID: <20240507091552.090ad6ec@Tarkus> + +On Tue, 7 May 2024 10:07:59 +1200 +Simon Urbanek wrote: + +> That doesn't work - additional repositories are not allowed on CRAN +> other than in very exceptional cases, because it means the package +> cannot be installed by users making it somewhat pointless. + +I suppose that with(tools::CRAN_package_db(), +sum(!is.na(Additional_repositories)) / length(Additional_repositories)) += 0.7% does make it very rare. But not even for a weak dependency? Is +it for data packages only, as seems to be the focus of +[10.32614/RJ-2017-026]? The current wording of the CRAN policy makes it +sound like Additional_repositories is preferred to explaining the +non-mainstream weak dependencies in Description. + +So what should be done about the non-Bioconductor weak dependency +microViz? + +> As for the OP, can you post the name of the package and/or the link +> to the errors so I can have a look? + +Sharon has since got rid of the WARNING and now only has NOTEs due to +microViz and a URL to its repo in the Description: +https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.2_20240504_185748/Debian/00check.log + +If Additional_repositories: is the correct way to specify a +non-mainstream weak dependency for a CRAN package, the URL must be +specified as https://david-barnett.r-universe.dev/src/contrib, not just +https://david-barnett.r-universe.dev/. I am sorry for not getting it +right the first time. + +-- +Best regards, +Ivan + + +From @|mon@urb@nek @end|ng |rom R-project@org Tue May 7 08:56:03 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Tue, 7 May 2024 18:56:03 +1200 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: <20240507091552.090ad6ec@Tarkus> +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> + <20240504193210.0332d714@Tarkus> + <7205534A-6666-4EDE-B613-68AAAFED2F2D@R-project.org> + <20240507091552.090ad6ec@Tarkus> +Message-ID: + +Ivan, + +sorry if it wasn't clear, but this thread was about strong dependencies -- Sharon noted that phyloseq must remain strong dependency and asked how to deal with that (see all the parts you cut from this thread). Now that I finally have the package name I can check the details - apparently this only affects R-oldrel so presumable Bioc upgrade may fix this so I'll have a look tomorrow. + +Cheers, +Simon + + + +> On May 7, 2024, at 6:15 PM, Ivan Krylov wrote: +> +> On Tue, 7 May 2024 10:07:59 +1200 +> Simon Urbanek wrote: +> +>> That doesn't work - additional repositories are not allowed on CRAN +>> other than in very exceptional cases, because it means the package +>> cannot be installed by users making it somewhat pointless. +> +> I suppose that with(tools::CRAN_package_db(), +> sum(!is.na(Additional_repositories)) / length(Additional_repositories)) +> = 0.7% does make it very rare. But not even for a weak dependency? Is +> it for data packages only, as seems to be the focus of +> [10.32614/RJ-2017-026]? The current wording of the CRAN policy makes it +> sound like Additional_repositories is preferred to explaining the +> non-mainstream weak dependencies in Description. +> +> So what should be done about the non-Bioconductor weak dependency +> microViz? +> +>> As for the OP, can you post the name of the package and/or the link +>> to the errors so I can have a look? +> +> Sharon has since got rid of the WARNING and now only has NOTEs due to +> microViz and a URL to its repo in the Description: +> https://win-builder.r-project.org/incoming_pretest/HybridMicrobiomes_0.1.2_20240504_185748/Debian/00check.log +> +> If Additional_repositories: is the correct way to specify a +> non-mainstream weak dependency for a CRAN package, the URL must be +> specified as https://david-barnett.r-universe.dev/src/contrib, not just +> https://david-barnett.r-universe.dev/. I am sorry for not getting it +> right the first time. +> +> -- +> Best regards, +> Ivan +> + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Tue May 7 15:55:30 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Tue, 7 May 2024 09:55:30 -0400 +Subject: [R-pkg-devel] Linker / System Requirement +Message-ID: + +In my Makevars file (linked below) I link to ssl by adding `-lssl` to +`PKG_LIBS`. Since I do this, does libssl need to be added to the System +Requirements field? + +Makevars: +https://github.com/R-ArcGIS/arcgisgeocode/blob/8194a478a616f7ddc3a25bcb024c0534007bcd51/src/Makevars#L4 + +If so, is there a place that contains the standardized descriptions for +some of these more common system requirements? I suspect that means my +SystemRequirements would look a bit like: + + +SystemRequirements: Cargo (Rust's package manager), rustc, libssl + +Is that correct? + +Thanks all! I'm a bit out of my depth here! + + [[alternative HTML version deleted]] + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Tue May 7 20:03:42 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Tue, 7 May 2024 14:03:42 -0400 +Subject: [R-pkg-devel] Cannot repro failing CRAN autochecks +Message-ID: + +I've submitted an R package to CRAN and am failing checks *only on Debian* + +https://win-builder.r-project.org/incoming_pretest/arcgisutils_0.3.0_20240507_194020/Debian/00check.log + + +This NOTE does not appear in Ubuntu, Mac, or Windows checks +https://github.com/R-ArcGIS/arcgisutils/actions/runs/8989812276/job/24693685840 + +I've made an edit to the Makevars to specifically remove this directory, +but it seems to continue to persist. + +https://github.com/R-ArcGIS/arcgisutils/blob/ff8a0a1b936e27be16ac866aa16605b973d435c7/src/Makevars#L31-L35 + +Does anyone know how I can repro this NOTE or have an idea about what is +happening? + +I'm a bit at a loss and do not want to use CRAN as if it is a CI +system--its challenging enough as is. + +Thanks! + +Josiah + + [[alternative HTML version deleted]] + + +From kev|nu@hey @end|ng |rom gm@||@com Tue May 7 20:21:59 2024 +From: kev|nu@hey @end|ng |rom gm@||@com (Kevin Ushey) +Date: Tue, 7 May 2024 11:21:59 -0700 +Subject: [R-pkg-devel] Linker / System Requirement +In-Reply-To: +References: +Message-ID: + +Hi Josiah, + +Indeed, the right thing to do is to declare the library in the +SystemRequirements file. However, other than some specific documented +usages which affect how R builds the package (e.g. C++ standards and +GNU make), I believe the field is meant more just to inform users of +the external dependencies required, so they could install those +themselves before attempting to install the package. The R extensions +manual has: + +https://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file +> Dependencies external to the R system should be listed in the ?SystemRequirements? field, possibly amplified in a separate README file. This includes specifying a non-default C++ standard and the need for GNU make. + +Also note that, for any external dependency required by the package, +you should also check its existence in the package configure script. + +https://cran.r-project.org/doc/manuals/R-exts.html#Configure-and-cleanup +> Use this to detect if any nonstandard libraries are present such that corresponding code in the package can be disabled at install time rather than giving error messages when the package is compiled or used. + +The curl package (and its dependency on libcurl) is the first thing +that comes to mind and could be a useful reference. + +https://github.com/jeroen/curl/blob/master/DESCRIPTION#L21 +https://github.com/jeroen/curl/blob/master/configure + +Best, +Kevin + +On Tue, May 7, 2024 at 6:56?AM Josiah Parry wrote: +> +> In my Makevars file (linked below) I link to ssl by adding `-lssl` to +> `PKG_LIBS`. Since I do this, does libssl need to be added to the System +> Requirements field? +> +> Makevars: +> https://github.com/R-ArcGIS/arcgisgeocode/blob/8194a478a616f7ddc3a25bcb024c0534007bcd51/src/Makevars#L4 +> +> If so, is there a place that contains the standardized descriptions for +> some of these more common system requirements? I suspect that means my +> SystemRequirements would look a bit like: +> +> +> SystemRequirements: Cargo (Rust's package manager), rustc, libssl +> +> Is that correct? +> +> Thanks all! I'm a bit out of my depth here! +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From |kry|ov @end|ng |rom d|@root@org Tue May 7 20:40:31 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Tue, 7 May 2024 21:40:31 +0300 +Subject: [R-pkg-devel] Cannot repro failing CRAN autochecks +In-Reply-To: +References: +Message-ID: <20240507214031.0df7e144@Tarkus> + +? Tue, 7 May 2024 14:03:42 -0400 +Josiah Parry ?????: + +> This NOTE does not appear in Ubuntu, Mac, or Windows checks +> https://github.com/R-ArcGIS/arcgisutils/actions/runs/8989812276/job/24693685840 + +That's a bit strange. It fires for me in a local R CMD check for a test +package even without --as-cran. The code performing the check has been +in R since ~2010. + +> I've made an edit to the Makevars to specifically remove this +> directory, but it seems to continue to persist. + +It's too late for Makevars to exclude files from the source package +tarball. Use .Rbuildignore instead: +https://cran.r-project.org/doc/manuals/R-exts.html#Building-binary-packages + +I think that the line src/vendor/chrono/CITATION\\.cff will prevent the +file from appearing in the package tarball. + +-- +Best regards, +Ivan + + +From |kry|ov @end|ng |rom d|@root@org Tue May 7 20:58:49 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Tue, 7 May 2024 21:58:49 +0300 +Subject: [R-pkg-devel] Cannot repro failing CRAN autochecks +In-Reply-To: <20240507214031.0df7e144@Tarkus> +References: + <20240507214031.0df7e144@Tarkus> +Message-ID: <20240507215849.05e8c9c1@Tarkus> + +? Tue, 7 May 2024 21:40:31 +0300 +Ivan Krylov via R-package-devel ?????: + +> It's too late for Makevars to exclude files from the source package +> tarball. Use .Rbuildignore instead: + +Sorry, that was mostly misguided. .Rbuildignore won't help with the +contents of the Rust vendor tarball. + +1. Can you omit the .cff file from src/rust/vendor.tar.xz when building +it? + +2. I think that there is --exclude in both GNU tar and BSD tar. How +about tar --exclude="*.cff" -x -f rust/vendor.tar.xz ? + +3. From +, +it can be seen that the "clean" target does not get called. Can you +remove the *.cff file in the same Make target? + +-- +Best regards, +Ivan + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Tue May 7 20:59:35 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Tue, 7 May 2024 14:59:35 -0400 +Subject: [R-pkg-devel] Cannot repro failing CRAN autochecks +In-Reply-To: <20240507214031.0df7e144@Tarkus> +References: + <20240507214031.0df7e144@Tarkus> +Message-ID: + +Thanks, Ivan! + +As you can see, the directory is ignored already +https://github.com/R-ArcGIS/arcgisutils/blob/ff8a0a1b936e27be16ac866aa16605b973d435c7/.Rbuildignore#L14 + +The directory is created in the Makevars after the zip is untarred: + +https://github.com/R-ArcGIS/arcgisutils/blob/ff8a0a1b936e27be16ac866aa16605b973d435c7/src/Makevars#L17 + +Then the directory is removed during the clean phase I believe as well. + +I have other packages that use a similar makevars that are in CRAN. + +Since I can?t repro it I?m not sure how to debug it without submitting to +CRAN again. + + + +On Tue, May 7, 2024 at 14:40 Ivan Krylov wrote: + +> ? Tue, 7 May 2024 14:03:42 -0400 +> Josiah Parry ?????: +> +> > This NOTE does not appear in Ubuntu, Mac, or Windows checks +> > +> https://github.com/R-ArcGIS/arcgisutils +> /actions/runs/8989812276/job/24693685840 +> +> +> That's a bit strange. It fires for me in a local R CMD check for a test +> package even without --as-cran. The code performing the check has been +> in R since ~2010. +> +> > I've made an edit to the Makevars to specifically remove this +> > directory, but it seems to continue to persist. +> +> It's too late for Makevars to exclude files from the source package +> tarball. Use .Rbuildignore instead: +> https://cran.r-project.org/doc/manuals/R-exts.html#Building-binary-packages +> +> I think that the line src/vendor/chrono/CITATION\\.cff will prevent the +> file from appearing in the package tarball. +> +> -- +> Best regards, +> Ivan +> + + [[alternative HTML version deleted]] + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 14:53:00 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 08:53:00 -0400 +Subject: [R-pkg-devel] Cannot repro failing CRAN autochecks +In-Reply-To: <20240507215849.05e8c9c1@Tarkus> +References: + <20240507214031.0df7e144@Tarkus> <20240507215849.05e8c9c1@Tarkus> +Message-ID: + +Thanks to @yutannihilation for pointing out that the issue repros on +r-universe +https://github.com/r-universe/r-arcgis/actions/runs/8990426306/job/24695887245 +. + +Do folks know if there are any templates for the linux CRAN check? It +appears that the r-lib/actions linux checks don't cover all of the same +bases. I tried cribbing the r-universe one but it is a bit like unwinding a +cat's cradle. + +Waiting an hour for each r-universe check is not really an effective +strategy! ? + +On Tue, May 7, 2024 at 2:58?PM Ivan Krylov wrote: + +> ? Tue, 7 May 2024 21:40:31 +0300 +> Ivan Krylov via R-package-devel ?????: +> +> > It's too late for Makevars to exclude files from the source package +> > tarball. Use .Rbuildignore instead: +> +> Sorry, that was mostly misguided. .Rbuildignore won't help with the +> contents of the Rust vendor tarball. +> +> 1. Can you omit the .cff file from src/rust/vendor.tar.xz when building +> it? +> +> 2. I think that there is --exclude in both GNU tar and BSD tar. How +> about tar --exclude="*.cff" -x -f rust/vendor.tar.xz ? +> +> 3. From +> < +> https://win-builder.r-project.org/incoming_pretest/arcgisutils_0.3.0_20240507_194020/Debian/00install.out +> >, +> it can be seen that the "clean" target does not get called. Can you +> remove the *.cff file in the same Make target? +> +> -- +> Best regards, +> Ivan +> + + [[alternative HTML version deleted]] + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 17:02:20 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 11:02:20 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +Message-ID: + +I am sorry for blowing up this thread lately. + +I've submitted a package to CRAN that uses Rust which thus requires +dependencies to be vendored. https://github.com/R-ArcGIS/arcgisutils/ + +The vendored dependencies are 18mb when zipped and 16.4mb when zipped with +XZ -9e. The *installed package size is 1.2mb* on my Mac. + +CRAN has rejected this package with: + +* Size of tarball: 18099770 bytes* + +*Please reudce to less than 5 MB for a CRAN package.* + + +Due to the requirement to vendor my dependencies. I do not see any possible +way to compress 250mb of source code to <= 5mb. + +I suspect there are alternatives which have been handled in one-off +situations given that other packages require fairly large system +dependencies e.g. Arrow, DuckDB, torch etc. + +How do others handle this? + + [[alternative HTML version deleted]] + + +From ne@|@p@r|ch@rd@on @end|ng |rom gm@||@com Wed May 8 17:13:31 2024 +From: ne@|@p@r|ch@rd@on @end|ng |rom gm@||@com (Neal Richardson) +Date: Wed, 8 May 2024 11:13:31 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: +Message-ID: + +CRAN policy [1] says: "If the sources are too large, it is acceptable +to download them as part of installation, but do ensure that the +download is of a fixed version rather than the latest." So you could +try downloading the source in your configure script. Though be careful +not to be bitten by this other line from the policy: "Packages which +use Internet resources should fail gracefully with an informative +message if the resource is not available or has changed (and not give +a check warning nor error)." + +Neal + +[1]: https://cran.r-project.org/web/packages/policies.html + + +On Wed, May 8, 2024 at 11:03?AM Josiah Parry wrote: +> +> I am sorry for blowing up this thread lately. +> +> I've submitted a package to CRAN that uses Rust which thus requires +> dependencies to be vendored. https://github.com/R-ArcGIS/arcgisutils/ +> +> The vendored dependencies are 18mb when zipped and 16.4mb when zipped with +> XZ -9e. The *installed package size is 1.2mb* on my Mac. +> +> CRAN has rejected this package with: +> +> * Size of tarball: 18099770 bytes* +> +> *Please reudce to less than 5 MB for a CRAN package.* +> +> +> Due to the requirement to vendor my dependencies. I do not see any possible +> way to compress 250mb of source code to <= 5mb. +> +> I suspect there are alternatives which have been handled in one-off +> situations given that other packages require fairly large system +> dependencies e.g. Arrow, DuckDB, torch etc. +> +> How do others handle this? +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From z42d|r@j @end|ng |rom uco@e@ Wed May 8 17:30:46 2024 +From: z42d|r@j @end|ng |rom uco@e@ (Jose V. Die Ramon) +Date: Wed, 8 May 2024 17:30:46 +0200 +Subject: [R-pkg-devel] package removed from CRAN +Message-ID: + +Hello, + +I just discovered that my package 'refseqR' was removed from the CRAN repository on April 30th. +https://cran.r-project.org/web/packages/refseqR/index.html? + +This news is extremely upsetting, especially because I did not receive any communication or warning regarding the issue. Could anyone please help me understand the reasons behind this, or suggest any steps I should take to resolve it? + +Thanks, +Jose + +From @vr@h@m@@d|er @end|ng |rom gm@||@com Wed May 8 17:40:14 2024 +From: @vr@h@m@@d|er @end|ng |rom gm@||@com (Avraham Adler) +Date: Wed, 8 May 2024 11:40:14 -0400 +Subject: [R-pkg-devel] package removed from CRAN +In-Reply-To: +References: +Message-ID: + +According to the CRAN links +, +your package had an error on r-devel-windows-x86_64 and +r-patched-linux-x86_64 which was not addressed. Specifically, some +examples failed. See + +for more specific details. Usually, fixing the problem and +incrementing the version is enough to resubmit it to CRAN. + +Thanks, + +Avi + +On Wed, May 8, 2024 at 11:33?AM Jose V. Die Ramon wrote: +> +> Hello, +> +> I just discovered that my package 'refseqR' was removed from the CRAN repository on April 30th. +> https://cran.r-project.org/web/packages/refseqR/index.html? +> +> This news is extremely upsetting, especially because I did not receive any communication or warning regarding the issue. Could anyone please help me understand the reasons behind this, or suggest any steps I should take to resolve it? +> +> Thanks, +> Jose +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 17:50:44 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 18:50:44 +0300 +Subject: [R-pkg-devel] package removed from CRAN +In-Reply-To: +References: +Message-ID: <20240508185044.02c15ecd@arachnoid> + +? Wed, 8 May 2024 17:30:46 +0200 +"Jose V. Die Ramon" ?????: + +> Could anyone please help me understand the reasons behind this, or +> suggest any steps I should take to resolve it? + +Here's what I could find in +https://cran.r-project.org/src/contrib/PACKAGES.in: + +>> X-CRAN-Comment: Archived on 2024-04-30 for policy violation. +>> . +>> On Internet access. Also other errors. + +So Avi is right, this is about the tests and/or examples failing +(possibly due to problems on the remote server). + +If possible, try to emit errors with a special class set for +Internet-related errors. This will make it possible for your examples +and tests to catch them, as in: + +tests/*.R: + +tryCatch( + , + refseqR_internet_error = function(e) + message("Caught Internet-related error") +) + +-- +Best regards, +Ivan + + +From edd @end|ng |rom deb|@n@org Wed May 8 17:51:33 2024 +From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel) +Date: Wed, 8 May 2024 10:51:33 -0500 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: +Message-ID: <26171.40837.306936.873386@rob.eddelbuettel.com> + + +On 8 May 2024 at 11:02, Josiah Parry wrote: +| CRAN has rejected this package with: +| +| * Size of tarball: 18099770 bytes* +| +| *Please reudce to less than 5 MB for a CRAN package.* + +Are you by chance confusing a NOTE (issued, but can be overruled) with a +WARNING (more severe, likely a must-be-addressed) or ERROR? + +There are lots and lots of packages larger than 5mb -- see eg + + https://cran.r-project.org/src/contrib/?C=S;O=D + +which has a top-5 of + + rcdklibs 19mb + fastrmodels 15mb + prqlr 15mb + RFlocalfdr 14mb + acss.data 14mb + +and at least one of those is also Rust-using and hence a possible template. + +Dirk + +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 17:56:27 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 11:56:27 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: <26171.40837.306936.873386@rob.eddelbuettel.com> +References: + <26171.40837.306936.873386@rob.eddelbuettel.com> +Message-ID: + +Thank you, Dirk. This was a direct email from a CRAN member and not part of +the automatic checks. The whole email is below. I think the intent of the +message is "please resubmit." + +Thanks, we see: + + +> Size of tarball: 18099770 bytes + + + +Please reudce to less than 5 MB for a CRAN package. + + + +Best, + + +Yes, prqlr is a great Rust-based package! My other Rust based packages that +are on CRAN are based, in part on prqlr. + + +On Wed, May 8, 2024 at 11:51?AM Dirk Eddelbuettel wrote: + +> +> On 8 May 2024 at 11:02, Josiah Parry wrote: +> | CRAN has rejected this package with: +> | +> | * Size of tarball: 18099770 bytes* +> | +> | *Please reudce to less than 5 MB for a CRAN package.* +> +> Are you by chance confusing a NOTE (issued, but can be overruled) with a +> WARNING (more severe, likely a must-be-addressed) or ERROR? +> +> There are lots and lots of packages larger than 5mb -- see eg +> +> https://cran.r-project.org/src/contrib/?C=S;O=D +> +> which has a top-5 of +> +> rcdklibs 19mb +> fastrmodels 15mb +> prqlr 15mb +> RFlocalfdr 14mb +> acss.data 14mb +> +> and at least one of those is also Rust-using and hence a possible template. +> +> Dirk +> +> -- +> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org +> + + [[alternative HTML version deleted]] + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 20:08:36 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 14:08:36 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + +Message-ID: + +Thank you, Neal! + +I took some inspiration from the arrow-r github repo and ch 1.2 of the +manual + +*If your configure script needs auxiliary files, it is recommended that you +> ship them in a tools directory (as R itself does).* + + +With ChatGPT's ability to write autoconf, I *think *I have something that +can work. + +The configure file runs tools/get-deps.R which will download the +dependencies from the repo if available and verify the checksums. +If the checksums don't match, an error is thrown, otherwise it can +continue. I believe this meets the requirements of CRAN? + +Repo: https://github.com/R-ArcGIS/arcgisutils/tree/main/tools + +On Wed, May 8, 2024 at 11:13?AM Neal Richardson +wrote: + +> CRAN policy [1] says: "If the sources are too large, it is acceptable +> to download them as part of installation, but do ensure that the +> download is of a fixed version rather than the latest." So you could +> try downloading the source in your configure script. Though be careful +> not to be bitten by this other line from the policy: "Packages which +> use Internet resources should fail gracefully with an informative +> message if the resource is not available or has changed (and not give +> a check warning nor error)." +> +> Neal +> +> [1]: https://cran.r-project.org/web/packages/policies.html +> +> +> On Wed, May 8, 2024 at 11:03?AM Josiah Parry +> wrote: +> > +> > I am sorry for blowing up this thread lately. +> > +> > I've submitted a package to CRAN that uses Rust which thus requires +> > dependencies to be vendored. https://github.com/R-ArcGIS/arcgisutils/ +> > +> > The vendored dependencies are 18mb when zipped and 16.4mb when zipped +> with +> > XZ -9e. The *installed package size is 1.2mb* on my Mac. +> > +> > CRAN has rejected this package with: +> > +> > * Size of tarball: 18099770 bytes* +> > +> > *Please reudce to less than 5 MB for a CRAN package.* +> > +> > +> > Due to the requirement to vendor my dependencies. I do not see any +> possible +> > way to compress 250mb of source code to <= 5mb. +> > +> > I suspect there are alternatives which have been handled in one-off +> > situations given that other packages require fairly large system +> > dependencies e.g. Arrow, DuckDB, torch etc. +> > +> > How do others handle this? +> > +> > [[alternative HTML version deleted]] +> > +> > ______________________________________________ +> > R-package-devel at r-project.org mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Wed May 8 21:32:00 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Wed, 8 May 2024 22:32:00 +0300 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + + +Message-ID: <20240508223200.4d659fe4@Tarkus> + +? Wed, 8 May 2024 14:08:36 -0400 +Josiah Parry ?????: + +> With ChatGPT's ability to write autoconf, I *think *I have something +> that can work. + +You don't have to write autoconf if your configure.ac is mostly a plain +shell script. You can write the configure script itself. Set the PATH +and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the +regular, non-multiarch configure for Unix-like systems) or exec +"${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in +configure.win, which you'll also need). You've already wrote the rest +of the code in a language you know well: R. + +Autoconf would be useful if you had system-specific dependencies with +the need to perform lots of compile tests. Those would have been a pain +to set up in R. Here you mostly need sys.which() instead of +AC_CHECK_PROGS and command -v. + +> The configure file runs tools/get-deps.R which will download the +> dependencies from the repo if available and verify the checksums. + +One of the pain points is the need for a strong, cryptographically +secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake +build, you would be able to use cmake's built in strong hashes (such as +SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only +requires a "checksum". If you figure out a way to use a strong hash +from tools/configure.R for the downloaded tarball, please let us know. + +> If the checksums don't match, an error is thrown, otherwise it can +> continue. I believe this meets the requirements of CRAN? + +The other important CRAN requirement is to store the vendor tarball +somewhere as permanent as CRAN itself (see the caveats at the bottom of +https://cran.r-project.org/web/packages/using_rust.html), that is, not +GitHub. I think that Zenodo counts as a sufficiently reliable store. + +-- +Best regards, +Ivan + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 22:01:23 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 16:01:23 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: <20240508223200.4d659fe4@Tarkus> +References: + + + <20240508223200.4d659fe4@Tarkus> +Message-ID: + +Thank you, Ivan, for your really thoughtful feedback! I really appreciate +it! + + - I'll see if there are any base R packages that support SHA-2 or SHA-3. + - I'll see if I can get the configure.ac to make the appropriate Rscript + call for configure.win. + - I think the idea of having a single `confgure.ac` file to generate + both configure and configure.win is nice. Guidance with GitHub +actions and + ChatGPT is essentially a must for me since my bash is remedial at best. + +Regarding the permanent storage requirement, I find it to be very strange. +I've personally never heard of Zenodo until just now! Does the CRAN team +have recommendations for what is considered "as sufficiently reliable?" I +have repos that have persisted for almost 10 years. I think that is +sufficiently reliable! + +The requirement to avoid GitHub feels surprisingly anachronistic given how +central it is to the vast majority of software development. The alternative +I can think of is to create a CDN on cloudflare or something to store the +file independently. + +Are there any avenues to have CRAN clarify their positions outside of +one-off processes? It would be quite unfortunate to go through all the work +of creating a way to build, store, and retrieve the dependencies only for +CRAN to decide they don't support it. + + +On Wed, May 8, 2024 at 3:32?PM Ivan Krylov wrote: + +> ? Wed, 8 May 2024 14:08:36 -0400 +> Josiah Parry ?????: +> +> > With ChatGPT's ability to write autoconf, I *think *I have something +> > that can work. +> +> You don't have to write autoconf if your configure.ac is mostly a plain +> shell script. You can write the configure script itself. Set the PATH +> and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the +> regular, non-multiarch configure for Unix-like systems) or exec +> "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in +> configure.win, which you'll also need). You've already wrote the rest +> of the code in a language you know well: R. +> +> Autoconf would be useful if you had system-specific dependencies with +> the need to perform lots of compile tests. Those would have been a pain +> to set up in R. Here you mostly need sys.which() instead of +> AC_CHECK_PROGS and command -v. +> +> > The configure file runs tools/get-deps.R which will download the +> > dependencies from the repo if available and verify the checksums. +> +> One of the pain points is the need for a strong, cryptographically +> secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake +> build, you would be able to use cmake's built in strong hashes (such as +> SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only +> requires a "checksum". If you figure out a way to use a strong hash +> from tools/configure.R for the downloaded tarball, please let us know. +> +> > If the checksums don't match, an error is thrown, otherwise it can +> > continue. I believe this meets the requirements of CRAN? +> +> The other important CRAN requirement is to store the vendor tarball +> somewhere as permanent as CRAN itself (see the caveats at the bottom of +> https://cran.r-project.org/web/packages/using_rust.html), that is, not +> GitHub. I think that Zenodo counts as a sufficiently reliable store. +> +> -- +> Best regards, +> Ivan +> + + [[alternative HTML version deleted]] + + +From ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de Wed May 8 22:06:04 2024 +From: ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de (Uwe Ligges) +Date: Wed, 8 May 2024 22:06:04 +0200 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + <26171.40837.306936.873386@rob.eddelbuettel.com> + +Message-ID: <5b19835e-e8c7-4cda-8034-9a03c067dbfd@statistik.tu-dortmund.de> + + + +On 08.05.2024 17:56, Josiah Parry wrote: +> Thank you, Dirk. This was a direct email from a CRAN member and not part of +> the automatic checks. The whole email is below. I think the intent of the +> message is "please resubmit." + + +Well, the CRAN maintainer has not spotted this is abour rust code. This +was not indicated in your mail, hence you got direct rejection. + +Best, +Uwe Ligges + + + + + +> Thanks, we see: +> +> +>> Size of tarball: 18099770 bytes +> +> +> +> Please reudce to less than 5 MB for a CRAN package. +> +> +> +> Best, +> +> +> Yes, prqlr is a great Rust-based package! My other Rust based packages that +> are on CRAN are based, in part on prqlr. +> +> +> On Wed, May 8, 2024 at 11:51?AM Dirk Eddelbuettel wrote: +> +>> +>> On 8 May 2024 at 11:02, Josiah Parry wrote: +>> | CRAN has rejected this package with: +>> | +>> | * Size of tarball: 18099770 bytes* +>> | +>> | *Please reudce to less than 5 MB for a CRAN package.* +>> +>> Are you by chance confusing a NOTE (issued, but can be overruled) with a +>> WARNING (more severe, likely a must-be-addressed) or ERROR? +>> +>> There are lots and lots of packages larger than 5mb -- see eg +>> +>> https://cran.r-project.org/src/contrib/?C=S;O=D +>> +>> which has a top-5 of +>> +>> rcdklibs 19mb +>> fastrmodels 15mb +>> prqlr 15mb +>> RFlocalfdr 14mb +>> acss.data 14mb +>> +>> and at least one of those is also Rust-using and hence a possible template. +>> +>> Dirk +>> +>> -- +>> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org +>> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + +From jo@|@h@p@rry @end|ng |rom gm@||@com Wed May 8 22:10:15 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Wed, 8 May 2024 16:10:15 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: <5b19835e-e8c7-4cda-8034-9a03c067dbfd@statistik.tu-dortmund.de> +References: + <26171.40837.306936.873386@rob.eddelbuettel.com> + + <5b19835e-e8c7-4cda-8034-9a03c067dbfd@statistik.tu-dortmund.de> +Message-ID: + +That's a good point! My apologies for not making that abundantly clear. + +Regardless, I think it is a fair ask to not submit massive tarballs of +dependencies. +Clarifying how we might be able to store the dependencies *outside *of CRAN +would be good to figure out. +This would help packages like polars be able to exist on CRAN. + +On Wed, May 8, 2024 at 4:06?PM Uwe Ligges +wrote: + +> +> +> On 08.05.2024 17:56, Josiah Parry wrote: +> > Thank you, Dirk. This was a direct email from a CRAN member and not part +> of +> > the automatic checks. The whole email is below. I think the intent of the +> > message is "please resubmit." +> +> +> Well, the CRAN maintainer has not spotted this is abour rust code. This +> was not indicated in your mail, hence you got direct rejection. +> +> Best, +> Uwe Ligges +> +> +> +> +> +> > Thanks, we see: +> > +> > +> >> Size of tarball: 18099770 bytes +> > +> > +> > +> > Please reudce to less than 5 MB for a CRAN package. +> > +> > +> > +> > Best, +> > +> > +> > Yes, prqlr is a great Rust-based package! My other Rust based packages +> that +> > are on CRAN are based, in part on prqlr. +> > +> > +> > On Wed, May 8, 2024 at 11:51?AM Dirk Eddelbuettel +> wrote: +> > +> >> +> >> On 8 May 2024 at 11:02, Josiah Parry wrote: +> >> | CRAN has rejected this package with: +> >> | +> >> | * Size of tarball: 18099770 bytes* +> >> | +> >> | *Please reudce to less than 5 MB for a CRAN package.* +> >> +> >> Are you by chance confusing a NOTE (issued, but can be overruled) with a +> >> WARNING (more severe, likely a must-be-addressed) or ERROR? +> >> +> >> There are lots and lots of packages larger than 5mb -- see eg +> >> +> >> https://cran.r-project.org/src/contrib/?C=S;O=D +> >> +> >> which has a top-5 of +> >> +> >> rcdklibs 19mb +> >> fastrmodels 15mb +> >> prqlr 15mb +> >> RFlocalfdr 14mb +> >> acss.data 14mb +> >> +> >> and at least one of those is also Rust-using and hence a possible +> template. +> >> +> >> Dirk +> >> +> >> -- +> >> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org +> >> +> > +> > [[alternative HTML version deleted]] +> > +> > ______________________________________________ +> > R-package-devel at r-project.org mailing list +> > https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From bbo|ker @end|ng |rom gm@||@com Wed May 8 22:12:31 2024 +From: bbo|ker @end|ng |rom gm@||@com (Ben Bolker) +Date: Wed, 8 May 2024 16:12:31 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + + + <20240508223200.4d659fe4@Tarkus> + +Message-ID: + + Zenodo and OSF (see e.g. +) are both non-profit +organizations that support archiving -- that is, they both make stronger +guarantees of permanent availability than GitHub does. Possibly Software +Heritage https://www.softwareheritage.org/features/ ? + + Zenodo has convenient GitHub integration. + +On 2024-05-08 4:01 p.m., Josiah Parry wrote: +> Thank you, Ivan, for your really thoughtful feedback! I really appreciate +> it! +> +> - I'll see if there are any base R packages that support SHA-2 or SHA-3. +> - I'll see if I can get the configure.ac to make the appropriate Rscript +> call for configure.win. +> - I think the idea of having a single `confgure.ac` file to generate +> both configure and configure.win is nice. Guidance with GitHub +> actions and +> ChatGPT is essentially a must for me since my bash is remedial at best. +> +> Regarding the permanent storage requirement, I find it to be very strange. +> I've personally never heard of Zenodo until just now! Does the CRAN team +> have recommendations for what is considered "as sufficiently reliable?" I +> have repos that have persisted for almost 10 years. I think that is +> sufficiently reliable! +> +> The requirement to avoid GitHub feels surprisingly anachronistic given how +> central it is to the vast majority of software development. The alternative +> I can think of is to create a CDN on cloudflare or something to store the +> file independently. +> +> Are there any avenues to have CRAN clarify their positions outside of +> one-off processes? It would be quite unfortunate to go through all the work +> of creating a way to build, store, and retrieve the dependencies only for +> CRAN to decide they don't support it. +> +> +> On Wed, May 8, 2024 at 3:32?PM Ivan Krylov wrote: +> +>> ? Wed, 8 May 2024 14:08:36 -0400 +>> Josiah Parry ?????: +>> +>>> With ChatGPT's ability to write autoconf, I *think *I have something +>>> that can work. +>> +>> You don't have to write autoconf if your configure.ac is mostly a plain +>> shell script. You can write the configure script itself. Set the PATH +>> and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the +>> regular, non-multiarch configure for Unix-like systems) or exec +>> "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in +>> configure.win, which you'll also need). You've already wrote the rest +>> of the code in a language you know well: R. +>> +>> Autoconf would be useful if you had system-specific dependencies with +>> the need to perform lots of compile tests. Those would have been a pain +>> to set up in R. Here you mostly need sys.which() instead of +>> AC_CHECK_PROGS and command -v. +>> +>>> The configure file runs tools/get-deps.R which will download the +>>> dependencies from the repo if available and verify the checksums. +>> +>> One of the pain points is the need for a strong, cryptographically +>> secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake +>> build, you would be able to use cmake's built in strong hashes (such as +>> SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only +>> requires a "checksum". If you figure out a way to use a strong hash +>> from tools/configure.R for the downloaded tarball, please let us know. +>> +>>> If the checksums don't match, an error is thrown, otherwise it can +>>> continue. I believe this meets the requirements of CRAN? +>> +>> The other important CRAN requirement is to store the vendor tarball +>> somewhere as permanent as CRAN itself (see the caveats at the bottom of +>> https://cran.r-project.org/web/packages/using_rust.html), that is, not +>> GitHub. I think that Zenodo counts as a sufficiently reliable store. +>> +>> -- +>> Best regards, +>> Ivan +>> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + +-- +Dr. Benjamin Bolker +Professor, Mathematics & Statistics and Biology, McMaster University +Director, School of Computational Science and Engineering +(Acting) Graduate chair, Mathematics & Statistics + > E-mail is sent at my convenience; I don't expect replies outside of +working hours. + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Wed May 8 23:48:17 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Wed, 8 May 2024 17:48:17 -0400 (EDT) +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + <26171.40837.306936.873386@rob.eddelbuettel.com> + +Message-ID: + + + +On Wed, 8 May 2024, Josiah Parry wrote: + +> +> +> Yes, prqlr is a great Rust-based package! My other Rust based packages that +> are on CRAN are based, in part on prqlr. +> +> + +If there are many packages based on Rust that require common code, would +it make sense to make a single "rust" compatibility package that they can +depend on ? + +best + +Vladimir Dergachev + + +From j|@c@@hu|@m@n @end|ng |rom gm@||@com Wed May 8 10:37:28 2024 +From: j|@c@@hu|@m@n @end|ng |rom gm@||@com (Jisca Huisman) +Date: Wed, 8 May 2024 10:37:28 +0200 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +Message-ID: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> + +Hello, + +I like to use write() in Fortran code to combine text with some integers +& doubles, to pass runtime information to R in a way that is prettier +and more legible than with intpr() & dblepr(). In the past any calls to +write() were strictly forbidden in Fortran code, as apparently it messed +something up internally (I cannot recall the details). But from 'writing +R extensions' it seems that there have been quite a few changes with +respect to support for Fortran code, and it currently reads: + + +6.5.1 Printing from Fortran + +On many systems Fortran|write|and|print|statements can be used, but the +output may not interleave well with that of C, and may be invisible +onGUIinterfaces. They are not portable and best avoided. + + +To be more specific, would the subroutine below be allowed? Is it needed +to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() +instead of intpr() ?) Is there an alternative without write() to get the +same result? + + +subroutine Rprint_pretty(iter, x) + ??? integer, intent(IN) :: iter + ??? double precision, intent(IN) :: x + ??? integer :: date_time_values(8), nchar, IntDummy(0) + ??? character(len=8) :: time_now + ??? character(len=200) :: msg_to_R + + ??? call date_and_time(VALUES=date_time_values) + ??? write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) + ??? write(msg_to_R, '(a8, " i: ", i5, "? value: ", f8.2)') time_now, +iter, x + + ??? nchar = len(trim(msg_to_R)) + ?? call intpr(trim(msg_to_R), nchar, IntDummy, 0) + + ? end subroutine Rprint_pretty + + +Thanks! + + + [[alternative HTML version deleted]] + + +From othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com Wed May 8 18:52:51 2024 +From: othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com (Othman El Hammouchi) +Date: Wed, 08 May 2024 16:52:51 +0000 +Subject: [R-pkg-devel] flang doesn't support derived types +Message-ID: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> + +Hello everyone, this is my first post on the mailing list (as well as the first package I'm attempting to publish), so please forgive any obvious errors. + +I'm using a lot of Fortran code which relies on derived types to manage data structures. The package compiles fine on Windows, Linux and Mac and passes all checks, including the CI pipeline on GitHub provided by the RStudio folks. However, upon submission I received an automatic reply shortly afterwards saying the build had failed on CRAN's servers for Debian. The log gives the following error: + +flang/lib/Lower/CallInterface.cpp:949: not yet implemented: support for polymorphic types + +I tried searching this mailing list as well as the llvm docs for a precedent or explanation, without much success. The baffling thing is that my code doesn't use polymorphism at all as far as I can tell, they're just DTs with bound procedures (I don't think the Fortran standard considers this polymorphic?). My question is: what can I do about it? This is a compiler issue, but I doesn't seem from "Writing R Extensions" that CRAN allows you to check the installed compiler and abort the install if an unsupported one is detected. However, it's not really a package developer's fault that the compiler doesn't support the standard. + +Thanks in advance, + +Othman El Hammouchi + [[alternative HTML version deleted]] + + +From er|nm@hodge@@ @end|ng |rom gm@||@com Thu May 9 02:51:46 2024 +From: er|nm@hodge@@ @end|ng |rom gm@||@com (Erin Hodgess) +Date: Wed, 8 May 2024 18:51:46 -0600 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +In-Reply-To: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +References: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +Message-ID: + +Hi Jisca: + +I have used the write successfully. I?m not sure if this matters or not, +but I am using WSL 2 with Ubuntu 22.04 installed. It works fine with R => +4.0. + +Hope this helps. + +Sincerely, +Erin + +Erin Hodgess, PhD +mailto: erinm.hodgess at gmail.com + + +On Wed, May 8, 2024 at 6:49?PM Jisca Huisman +wrote: + +> Hello, +> +> I like to use write() in Fortran code to combine text with some integers +> & doubles, to pass runtime information to R in a way that is prettier +> and more legible than with intpr() & dblepr(). In the past any calls to +> write() were strictly forbidden in Fortran code, as apparently it messed +> something up internally (I cannot recall the details). But from 'writing +> R extensions' it seems that there have been quite a few changes with +> respect to support for Fortran code, and it currently reads: +> +> +> 6.5.1 Printing from Fortran +> +> On many systems Fortran|write|and|print|statements can be used, but the +> output may not interleave well with that of C, and may be invisible +> onGUIinterfaces. They are not portable and best avoided. +> +> +> To be more specific, would the subroutine below be allowed? Is it needed +> to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() +> instead of intpr() ?) Is there an alternative without write() to get the +> same result? +> +> +> subroutine Rprint_pretty(iter, x) +> integer, intent(IN) :: iter +> double precision, intent(IN) :: x +> integer :: date_time_values(8), nchar, IntDummy(0) +> character(len=8) :: time_now +> character(len=200) :: msg_to_R +> +> call date_and_time(VALUES=date_time_values) +> write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) +> write(msg_to_R, '(a8, " i: ", i5, " value: ", f8.2)') time_now, +> iter, x +> +> nchar = len(trim(msg_to_R)) +> call intpr(trim(msg_to_R), nchar, IntDummy, 0) +> +> end subroutine Rprint_pretty +> +> +> Thanks! +> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + [[alternative HTML version deleted]] + + +From @@meh@@bdu|@h @end|ng |rom k@u@t@edu@@@ Thu May 9 05:20:58 2024 +From: @@meh@@bdu|@h @end|ng |rom k@u@t@edu@@@ (Sameh Abdulah) +Date: Thu, 9 May 2024 03:20:58 +0000 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +Message-ID: + +Hi, + +I need to serialize and save a 20K x 20K matrix as a binary file. This process is significantly slower in R compared to Python (4X slower). + +I'm not sure about the best approach to optimize the below code. Is it possible to parallelize the serialization function to enhance performance? + + + n <- 20000^2 + cat("Generating matrices ... ") + INI.TIME <- proc.time() + A <- matrix(runif(n), ncol = m) + END_GEN.TIME <- proc.time() + arg_ser <- serialize(object = A, connection = NULL) + + END_SER.TIME <- proc.time() + con <- file(description = "matrix_file", open = "wb") + writeBin(object = arg_ser, con = con) + close(con) + END_WRITE.TIME <- proc.time() + con <- file(description = "matrix_file", open = "rb") + par_raw <- readBin(con, what = raw(), n = file.info("matrix_file")$size) + END_READ.TIME <- proc.time() + B <- unserialize(connection = par_raw) + close(con) + END_DES.TIME <- proc.time() + TIME <- END_GEN.TIME - INI.TIME + cat("Generation time", TIME[3], " seconds.") + + TIME <- END_SER.TIME - END_GEN.TIME + cat("Serialization time", TIME[3], " seconds.") + + TIME <- END_WRITE.TIME - END_SER.TIME + cat("Writting time", TIME[3], " seconds.") + + TIME <- END_READ.TIME - END_WRITE.TIME + cat("Read time", TIME[3], " seconds.") + + TIME <- END_DES.TIME - END_READ.TIME + cat("Deserialize time", TIME[3], " seconds.") + + + + +Best, +--Sameh + +-- + +This message and its contents, including attachments are intended solely +for the original recipient. If you are not the intended recipient or have +received this message in error, please notify me immediately and delete +this message from your computer system. Any unauthorized use or +distribution is prohibited. Please consider the environment before printing +this email. + + [[alternative HTML version deleted]] + + +From edd @end|ng |rom deb|@n@org Thu May 9 05:35:34 2024 +From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel) +Date: Wed, 8 May 2024 22:35:34 -0500 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: +Message-ID: <26172.17542.683175.713755@rob.eddelbuettel.com> + + +On 9 May 2024 at 03:20, Sameh Abdulah wrote: +| I need to serialize and save a 20K x 20K matrix as a binary file. + +Hm that is an incomplete specification: _what_ do you want to do with it? +Read it back in R? Share it with other languages (like Python) ? I.e. what +really is your use case? Also, you only seem to use readBin / writeBin. Why +not readRDS / saveRDS which at least give you compression? + +If it is to read/write from / to R look into the qs package. It is good. The +README.md at its repo has benchmarks: https://github.com/traversc/qs If you +want to index into the stored data look into fst. Else also look at databases + +Dirk + +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + + +From @@meh@@bdu|@h @end|ng |rom k@u@t@edu@@@ Thu May 9 05:56:25 2024 +From: @@meh@@bdu|@h @end|ng |rom k@u@t@edu@@@ (Sameh Abdulah) +Date: Thu, 9 May 2024 03:56:25 +0000 +Subject: [R-pkg-devel] [EXTERNAL] Re: Fast Matrix Serialization in R? +In-Reply-To: <26172.17542.683175.713755@rob.eddelbuettel.com> +References: + <26172.17542.683175.713755@rob.eddelbuettel.com> +Message-ID: + +Thanks! + + +I want to save data from a matrix to a file and then retrieve it later while running R code, all within R. + +As long as the compression doesn't result in data loss, it should be suitable for my needs. + + +Best, +--Sameh + + + +From: Dirk Eddelbuettel +Date: Thursday, May 9, 2024 at 6:35?AM +To: Sameh Abdulah +Cc: r-package-devel at r-project.org +Subject: [EXTERNAL] Re: [R-pkg-devel] Fast Matrix Serialization in R? + +On 9 May 2024 at 03:20, Sameh Abdulah wrote: +| I need to serialize and save a 20K x 20K matrix as a binary file. + +Hm that is an incomplete specification: _what_ do you want to do with it? +Read it back in R? Share it with other languages (like Python) ? I.e. what +really is your use case? Also, you only seem to use readBin / writeBin. Why +not readRDS / saveRDS which at least give you compression? + +If it is to read/write from / to R look into the qs package. It is good. The +README.md at its repo has benchmarks: https://urldefense.com/v3/__https://github.com/traversc/qs__;!!Nmw4Hv0!zZitnMd5aMqDWhLShhC5Npmd8pkisFVejC3grX2YGSGWFZihVaHAezYyo5nXbAwIdqCj2T8Nbk-Yofxa-y8$ If you +want to index into the stored data look into fst. Else also look at databases + +Dirk + +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + +-- + +This message and its contents, including attachments are intended solely +for the original recipient. If you are not the intended recipient or have +received this message in error, please notify me immediately and delete +this message from your computer system. Any unauthorized use or +distribution is prohibited. Please consider the environment before printing +this email. + + [[alternative HTML version deleted]] + + +From berw|n@tur|@ch @end|ng |rom gm@||@com Thu May 9 06:30:52 2024 +From: berw|n@tur|@ch @end|ng |rom gm@||@com (Berwin A Turlach) +Date: Thu, 9 May 2024 12:30:52 +0800 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +In-Reply-To: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +References: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +Message-ID: <20240509123052.3f1d5c3b@dep59159.uniwa.uwa.edu.au> + +Hi Jisca, + +On Wed, 8 May 2024 10:37:28 +0200 +Jisca Huisman wrote: + +> I like to use write() in Fortran code [...] But from 'writing R +> extensions' it seems that there have been quite a few changes with +> respect to support for Fortran code, and it currently reads: +> +> 6.5.1 Printing from Fortran +> +> On many systems Fortran|write|and|print|statements can be used, but +> the output may not interleave well with that of C, and may be +> invisible onGUIinterfaces. They are not portable and best avoided. + +I am not aware that there were any recent changes regarding printing +from Fortran recently, or that it was every strictly forbidden (perhaps +it is for packages that are submitted to CRAN?). In fact, R-exts.texi +for R 1.0.0 states pretty much the same as what you quoted from the +current WRE manual: + + @subsection Printing from Fortran + @cindex Printing from C + + In theory Fortran @code{write} and @code{print} statements can be + used, but the output may not interleave well with that of C, and will + be invisible on GUI interfaces. They are best avoided. + + Three subroutines are provided to ease the output of information from + Fortran code. + + @example + subroutine dblepr(@var{label}, @var{nchar}, @var{data}, @var{ndata}) + subroutine realpr(@var{label}, @var{nchar}, @var{data}, @var{ndata}) + subroutine intpr (@var{label}, @var{nchar}, @var{data}, @var{ndata}) + @end example + +Cheers, + + Berwin + + +From @|mon@urb@nek @end|ng |rom R-project@org Thu May 9 07:26:45 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Thu, 9 May 2024 17:26:45 +1200 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: +Message-ID: <3517F470-4DA5-4146-ADF9-5B26002AC650@R-project.org> + +Sameh, + +if it's a matrix, that's easy as you can write it directly which is the fastest possible way without compression - e.g. quick proof of concept: + +n <- 20000^2 +A <- matrix(runif(n), ncol = sqrt(n)) + +## write (dim + payload) +con <- file(description = "matrix_file", open = "wb") +system.time({ +writeBin(d <- dim(A), con) +dim(A)=NULL +writeBin(A, con) +dim(A)=d +}) +close(con) + +## read +con <- file(description = "matrix_file", open = "rb") +system.time({ +d <- readBin(con, 1L, 2) +A1 <- readBin(con, 1, d[1] * d[2]) +dim(A1) <- d +}) +close(con) +identical(A, A1) + + user system elapsed + 0.931 2.713 3.644 + user system elapsed + 0.089 1.360 1.451 +[1] TRUE + +So it's really just limited by the speed of your disk, parallelization won't help here. + +Note that in general you get faster read times by using compression as most data is reasonably compressible, so that's where parallelization can be useful. There are plenty of package with more tricks like mmapping the files etc., but the above is just base R. + +Cheers, +Simon + + + +> On 9/05/2024, at 3:20 PM, Sameh Abdulah wrote: +> +> Hi, +> +> I need to serialize and save a 20K x 20K matrix as a binary file. This process is significantly slower in R compared to Python (4X slower). +> +> I'm not sure about the best approach to optimize the below code. Is it possible to parallelize the serialization function to enhance performance? +> +> +> n <- 20000^2 +> cat("Generating matrices ... ") +> INI.TIME <- proc.time() +> A <- matrix(runif(n), ncol = m) +> END_GEN.TIME <- proc.time() +> arg_ser <- serialize(object = A, connection = NULL) +> +> END_SER.TIME <- proc.time() +> con <- file(description = "matrix_file", open = "wb") +> writeBin(object = arg_ser, con = con) +> close(con) +> END_WRITE.TIME <- proc.time() +> con <- file(description = "matrix_file", open = "rb") +> par_raw <- readBin(con, what = raw(), n = file.info("matrix_file")$size) +> END_READ.TIME <- proc.time() +> B <- unserialize(connection = par_raw) +> close(con) +> END_DES.TIME <- proc.time() +> TIME <- END_GEN.TIME - INI.TIME +> cat("Generation time", TIME[3], " seconds.") +> +> TIME <- END_SER.TIME - END_GEN.TIME +> cat("Serialization time", TIME[3], " seconds.") +> +> TIME <- END_WRITE.TIME - END_SER.TIME +> cat("Writting time", TIME[3], " seconds.") +> +> TIME <- END_READ.TIME - END_WRITE.TIME +> cat("Read time", TIME[3], " seconds.") +> +> TIME <- END_DES.TIME - END_READ.TIME +> cat("Deserialize time", TIME[3], " seconds.") +> +> +> +> +> Best, +> --Sameh +> +> -- +> +> This message and its contents, including attachments are intended solely +> for the original recipient. If you are not the intended recipient or have +> received this message in error, please notify me immediately and delete +> this message from your computer system. Any unauthorized use or +> distribution is prohibited. Please consider the environment before printing +> this email. +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +From j|@c@@hu|@m@n @end|ng |rom gm@||@com Thu May 9 08:33:34 2024 +From: j|@c@@hu|@m@n @end|ng |rom gm@||@com (Jisca Huisman) +Date: Thu, 9 May 2024 08:33:34 +0200 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +In-Reply-To: <20240509123052.3f1d5c3b@dep59159.uniwa.uwa.edu.au> +References: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> + <20240509123052.3f1d5c3b@dep59159.uniwa.uwa.edu.au> +Message-ID: + +Dear Berwin & Erin, + +Thanks for your replies. I should perhaps have clarified - this is for a +package on CRAN. + +In my experience anything with Fortran write will get a NOTE from CRAN's +auto-check: + +Check: compiled code, Result: NOTE + File 'sequoia/libs/sequoia.so': + Found '_gfortran_st_write', possibly from 'write' (Fortran), 'print' + (Fortran) + Object: 'sequoia.o' + + Compiled code should not call entry points which might terminate R nor + write to stdout/stderr instead of to the console, nor use Fortran I/O + nor system RNGs. + + +In the past (2018) I've tried to `write` the iteration number to a char +to then combine into the message send to R with `dplepr`, but when I +tried to argue this was a false positive as it wasn't writing to a file +I got the following reply from UL: + + +> The manual says +> +> +> In particular, any package that makes use of Fortran I/O will when +> compiled on Windows interfere with C I/O: when the Fortran I/O support +> code is initialized (typically when the package is loaded) the C +> stdout and stderr are switched to LF line endings. +> +> +> and both of us read too quickly: when the Fortran I/O support code is +> initialized (typically when the package is loaded) the C stdout and +> stderr are switched to LF line endings. +> This happens alway, even if you write to another variable. +> +> You could of course write C interface code to do the conversion if you +> have to rely on write(). + +So what I'm wondering now - has the issue with the switch to LF line +endings been fixed, and is it OK to use non-file `write`? Because I +don't really want to make the time to figure out how to 'write C +interface code to do the conversion' just for some prettier messages... + + +Thanks for your help! + + + + +On Thu, 09/05/2024 06:30, Berwin A Turlach wrote: +> Hi Jisca, +> +> On Wed, 8 May 2024 10:37:28 +0200 +> Jisca Huisman wrote: +> +>> I like to use write() in Fortran code [...] But from 'writing R +>> extensions' it seems that there have been quite a few changes with +>> respect to support for Fortran code, and it currently reads: +>> +>> 6.5.1 Printing from Fortran +>> +>> On many systems Fortran|write|and|print|statements can be used, but +>> the output may not interleave well with that of C, and may be +>> invisible onGUIinterfaces. They are not portable and best avoided. +> I am not aware that there were any recent changes regarding printing +> from Fortran recently, or that it was every strictly forbidden (perhaps +> it is for packages that are submitted to CRAN?). In fact, R-exts.texi +> for R 1.0.0 states pretty much the same as what you quoted from the +> current WRE manual: +> +> @subsection Printing from Fortran +> @cindex Printing from C +> +> In theory Fortran @code{write} and @code{print} statements can be +> used, but the output may not interleave well with that of C, and will +> be invisible on GUI interfaces. They are best avoided. +> +> Three subroutines are provided to ease the output of information from +> Fortran code. +> +> @example +> subroutine dblepr(@var{label}, @var{nchar}, @var{data}, @var{ndata}) +> subroutine realpr(@var{label}, @var{nchar}, @var{data}, @var{ndata}) +> subroutine intpr (@var{label}, @var{nchar}, @var{data}, @var{ndata}) +> @end example +> +> Cheers, +> +> Berwin + + +From bhh @end|ng |rom x@4@||@n| Thu May 9 13:08:10 2024 +From: bhh @end|ng |rom x@4@||@n| (Berend Hasselman) +Date: Thu, 9 May 2024 13:08:10 +0200 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +In-Reply-To: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +References: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> +Message-ID: <7A4A5FF4-26B6-49EA-BB4A-F916A2EC981A@xs4all.nl> + + +Hi, + +Have a look at package nleqslv to see how you can avoid Fortran write completely. +Look at the file src/nwout.c and the calls of various functions therein in the other fortran files. + +regards, + +Berend Hasselman + +> On 08-05-2024, at 10:37, Jisca Huisman wrote: +> +> Hello, +> +> I like to use write() in Fortran code to combine text with some integers +> & doubles, to pass runtime information to R in a way that is prettier +> and more legible than with intpr() & dblepr(). In the past any calls to +> write() were strictly forbidden in Fortran code, as apparently it messed +> something up internally (I cannot recall the details). But from 'writing +> R extensions' it seems that there have been quite a few changes with +> respect to support for Fortran code, and it currently reads: +> +> +> 6.5.1 Printing from Fortran +> +> On many systems Fortran|write|and|print|statements can be used, but the +> output may not interleave well with that of C, and may be invisible +> onGUIinterfaces. They are not portable and best avoided. +> +> +> To be more specific, would the subroutine below be allowed? Is it needed +> to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() +> instead of intpr() ?) Is there an alternative without write() to get the +> same result? +> +> +> subroutine Rprint_pretty(iter, x) +> integer, intent(IN) :: iter +> double precision, intent(IN) :: x +> integer :: date_time_values(8), nchar, IntDummy(0) +> character(len=8) :: time_now +> character(len=200) :: msg_to_R +> +> call date_and_time(VALUES=date_time_values) +> write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) +> write(msg_to_R, '(a8, " i: ", i5, " value: ", f8.2)') time_now, +> iter, x +> +> nchar = len(trim(msg_to_R)) +> call intpr(trim(msg_to_R), nchar, IntDummy, 0) +> +> end subroutine Rprint_pretty +> +> +> Thanks! +> +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From j|@c@@hu|@m@n @end|ng |rom gm@||@com Thu May 9 13:40:00 2024 +From: j|@c@@hu|@m@n @end|ng |rom gm@||@com (Jisca Huisman) +Date: Thu, 9 May 2024 13:40:00 +0200 +Subject: [R-pkg-devel] is Fortran write still strictly forbidden? +In-Reply-To: <7A4A5FF4-26B6-49EA-BB4A-F916A2EC981A@xs4all.nl> +References: <95b62a98-7920-4a36-8339-fce63a89e3e5@gmail.com> + <7A4A5FF4-26B6-49EA-BB4A-F916A2EC981A@xs4all.nl> +Message-ID: + +Hello Berend, + +Fantastic, thank you! I'm fairly sure I'll be able to figure something +out with your code as a guide. + +best, + +Jisca + + +On Thu, 09/05/2024 13:08, Berend Hasselman wrote: +> Hi, +> +> Have a look at package nleqslv to see how you can avoid Fortran write completely. +> Look at the file src/nwout.c and the calls of various functions therein in the other fortran files. +> +> regards, +> +> Berend Hasselman +> +>> On 08-05-2024, at 10:37, Jisca Huisman wrote: +>> +>> Hello, +>> +>> I like to use write() in Fortran code to combine text with some integers +>> & doubles, to pass runtime information to R in a way that is prettier +>> and more legible than with intpr() & dblepr(). In the past any calls to +>> write() were strictly forbidden in Fortran code, as apparently it messed +>> something up internally (I cannot recall the details). But from 'writing +>> R extensions' it seems that there have been quite a few changes with +>> respect to support for Fortran code, and it currently reads: +>> +>> +>> 6.5.1 Printing from Fortran +>> +>> On many systems Fortran|write|and|print|statements can be used, but the +>> output may not interleave well with that of C, and may be invisible +>> onGUIinterfaces. They are not portable and best avoided. +>> +>> +>> To be more specific, would the subroutine below be allowed? Is it needed +>> to declare R >= 4.0 (?) in the package DESCRIPTION (& then use labelpr() +>> instead of intpr() ?) Is there an alternative without write() to get the +>> same result? +>> +>> +>> subroutine Rprint_pretty(iter, x) +>> integer, intent(IN) :: iter +>> double precision, intent(IN) :: x +>> integer :: date_time_values(8), nchar, IntDummy(0) +>> character(len=8) :: time_now +>> character(len=200) :: msg_to_R +>> +>> call date_and_time(VALUES=date_time_values) +>> write(time_now, '(i2.2,":",i2.2,":",i2.2)') date_time_values(5:7) +>> write(msg_to_R, '(a8, " i: ", i5, " value: ", f8.2)') time_now, +>> iter, x +>> +>> nchar = len(trim(msg_to_R)) +>> call intpr(trim(msg_to_R), nchar, IntDummy, 0) +>> +>> end subroutine Rprint_pretty +>> +>> +>> Thanks! +>> +>> +>> [[alternative HTML version deleted]] +>> +>> ______________________________________________ +>> R-package-devel at r-project.org mailing list +>> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From vo|ody@ @end|ng |rom m|nd@pr|ng@com Thu May 9 13:58:43 2024 +From: vo|ody@ @end|ng |rom m|nd@pr|ng@com (Vladimir Dergachev) +Date: Thu, 9 May 2024 07:58:43 -0400 (EDT) +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: +Message-ID: + + + +On Thu, 9 May 2024, Sameh Abdulah wrote: + +> Hi, +> +> I need to serialize and save a 20K x 20K matrix as a binary file. This process is significantly slower in R compared to Python (4X slower). +> +> I'm not sure about the best approach to optimize the below code. Is it possible to parallelize the serialization function to enhance performance? + +Parallelization should not help - a single CPU thread should be able to +saturate your disk or your network, assuming you have a typical computer. + +The problem is possibly the conversion to text, writing it as binary +should be much faster. + +To add to other suggestions, you might want to try my package "RMVL" - +aside from fast writes, it also gives you ability to share data between +ultimate users of the package. + +best + +Vladimir Dergachev + +PS Example: + +library("RMVL") + +M<-mvl_open("test1.mvl", append=TRUE, create=TRUE) + +n <- 20000^2 +cat("Generating matrices ... ") +INI.TIME <- proc.time() +A <- matrix(runif(n), ncol = m) +END_GEN.TIME <- proc.time() + +mvl_write(M, A, name="A") + +mvl_close(M) + +END_SER.TIME <- proc.time() + + +# Use in another script: + +library("RMVL") + +M2<-mvl_open("test1.mvl") + +print(M2$A[1:10, 1:10]) + + +From ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de Thu May 9 15:38:27 2024 +From: ||gge@ @end|ng |rom @t@t|@t|k@tu-dortmund@de (Uwe Ligges) +Date: Thu, 9 May 2024 15:38:27 +0200 +Subject: [R-pkg-devel] package removed from CRAN +In-Reply-To: +References: +Message-ID: + + + +On 08.05.2024 17:30, Jose V. Die Ramon wrote: +> Hello, +> +> I just discovered that my package 'refseqR' was removed from the CRAN repository on April 30th. +> https://cran.r-project.org/web/packages/refseqR/index.html? +> +> This news is extremely upsetting, especially because I did not receive any communication or warning regarding the issue. Could anyone please help me understand the reasons behind this, or suggest any steps I should take to resolve it? +> +> Thanks, +> Jose + +Professor Ripley sent you email on April 16 and asked for a fix within 2 +weeks --- to your maintainer address which is apparently different from +the one you are using here. + +Best, +Uwe Ligges + +From |kry|ov @end|ng |rom d|@root@org Thu May 9 16:41:01 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 9 May 2024 17:41:01 +0300 +Subject: [R-pkg-devel] flang doesn't support derived types +In-Reply-To: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> +References: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> +Message-ID: <20240509174101.0c7edfd9@trisector> + +Dear Othman El Hammouchi, + +Welcome to R-package-devel! + +? Wed, 08 May 2024 16:52:51 +0000 +Othman El Hammouchi ?????: + +> However, upon submission I received an automatic reply shortly +> afterwards saying the build had failed on CRAN's servers for Debian. +> The log gives the following error: +> +> flang/lib/Lower/CallInterface.cpp:949: not yet implemented: support +> for polymorphic types + +Your use of contained procedures in class(t_mack_triangle) and +class(t_cl_res) signifies the derived types as being extensible and +thus potentially polymorphic. You'll have to replace class(...) with +type(...) and move the contained procedures out of the type definitions +(and maybe additionally make the types 'sequence' or 'bind(C)' to +signify them being non-extensible) to make the code work with flang-18. +I'm afraid this will also prevent you from defining destructors for +these types. + +flang-new can be a very disappointing compiler at times [*], but it's +what people do use in the real world, especially for 64-bit ARM +processors, so in order to keep our packages portable, we have to cater +to its whims. + +-- +Best regards, +Ivan + +[*] https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009987.html + + +From othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com Thu May 9 17:31:25 2024 +From: othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com (Othman El Hammouchi) +Date: Thu, 09 May 2024 15:31:25 +0000 +Subject: [R-pkg-devel] flang doesn't support derived types +In-Reply-To: <20240509174101.0c7edfd9@trisector> +References: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> + <20240509174101.0c7edfd9@trisector> +Message-ID: + +Dear Ivan, + +Thank you so much for taking the time. I'd already figured out my misunderstanding on polymorphism in the mean time. The flang limitations are quite unfortunate, especially since there's no way to know this in development. The CI pipeline provided by the RStudio folks uses gfortran, and as far as I know it's the standard compiler in most distributions. Do I understand it correctly that there is no way to specify a Fortran standard in the SystemRequirements? I had resubmitted my package in the mean time with a configure script that aborts the install if the compiler does not support polymorphism, but I understand that this is a fruitless avenue for CRAN? + +On the practical side, I did experiment with what you suggested. However, I'm now getting other errors about initialisation of allocatable arrays and the use of intrinsics like isnan, which would be impossible to take out. I should point out my local flang install is version 16, but I cannot install 18 on my system since it's in unstable (this again underscores the problem of developing under these constraints). + +What would you advise? And don't you think these Fortran constraints should be better documenten. + +Thanks for bearing with me, + +Othman El Hammouchi + +Sent from Proton Mail mobile + +-------- Original Message -------- +On 9 May 2024, 16:41, Ivan Krylov wrote: + +> Dear Othman El Hammouchi, Welcome to R-package-devel! ? Wed, 08 May 2024 16:52:51 +0000 Othman El Hammouchi ?????: > However, upon submission I received an automatic reply shortly > afterwards saying the build had failed on CRAN's servers for Debian. > The log gives the following error: > > flang/lib/Lower/CallInterface.cpp:949: not yet implemented: support > for polymorphic types Your use of contained procedures in class(t_mack_triangle) and class(t_cl_res) signifies the derived types as being extensible and thus potentially polymorphic. You'll have to replace class(...) with type(...) and move the contained procedures out of the type definitions (and maybe additionally make the types 'sequence' or 'bind(C)' to signify them being non-extensible) to make the code work with flang-18. I'm afraid this will also prevent you from defining destructors for these types. flang-new can be a very disappointing compiler at times [*], but it's what people do use in the real world, especially for 64-bit ARM processors, so in order to keep our packages portable, we have to cater to its whims. -- Best regards, Ivan [*] https://stat.ethz.ch/pipermail/r-package-devel/2023q4/009987.html + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Thu May 9 18:34:30 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 9 May 2024 19:34:30 +0300 +Subject: [R-pkg-devel] flang doesn't support derived types +In-Reply-To: +References: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> + <20240509174101.0c7edfd9@trisector> + +Message-ID: <20240509193430.1998b917@Tarkus> + +? Thu, 09 May 2024 15:31:25 +0000 +Othman El Hammouchi ?????: + +> Do I understand it correctly that there is no way to specify a +> Fortran standard in the SystemRequirements? + +It's possible (and even recommended) to describe the Fortran version +requirement in SystemRequirements [1], but this field is for now mostly +informational. I think I remember efforts to standardise it, but they +are far from complete. + +> I had resubmitted my package in the mean time with a configure script +> that aborts the install if the compiler does not support +> polymorphism, but I understand that this is a fruitless avenue for +> CRAN? + +Signs point to yes, at least judging by a previous time we had +flang-related problems [2]. On the other hand, there were relatively +easy workarounds that time, and here I'm not seeing anything as simple. + +> I should point out my local flang install is version 16, but I cannot +> install 18 on my system since it's in unstable (this again +> underscores the problem of developing under these constraints). + +Would you consider containers for this purpose? I was able to reproduce +the problem relatively quickly by starting podman run --rm -it +debian:sid and installing flang-18 in there. (Unlike Docker a few years +ago, podman can be installed straight from the repository, at least on +Debian, and doesn't require adding users to special groups in order to +work. Maybe Docker has also improved.) I don't like containers as a +basis for software distribution, but I can't deny that they are being +great at letting me quickly reproduce problems without installing 10 +different GNU/Linux distros. + +> What would you advise? And don't you think these Fortran constraints +> should be better documenten. + +I'm afraid I don't have any more specific advice besides testing your +workarounds with Debian Sid in a container or a virtual machine or a +chroot. I can try to take a look at more concrete problems. I hope you +will be able to find a relatively painless workaround. + +I do wish that flang-new would be a better compiler or at least a +better documented one, but instead of a list of features on their +website, I can only see "Getting Involved [3] for tips on how to get in +touch <...> and to learn more about the current status". There is only +so many projects one can get involved in. + +-- +Best regards, +Ivan + +[1] +https://cran.r-project.org/doc/manuals/R-exts.html#Using-modern-Fortran-code + +[2] +https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010065.html + +[3] +https://flang.llvm.org/docs/GettingInvolved.html + + +From |kry|ov @end|ng |rom d|@root@org Thu May 9 19:07:21 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Thu, 9 May 2024 20:07:21 +0300 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: +References: + + + <20240508223200.4d659fe4@Tarkus> + +Message-ID: <20240509200721.2209bad4@Tarkus> + +? Wed, 8 May 2024 16:01:23 -0400 +Josiah Parry ?????: + +> - I'll see if I can get the configure.ac to make the appropriate +> Rscript call for configure.win. +> - I think the idea of having a single `confgure.ac` file to +> generate both configure and configure.win is nice. Guidance with +> GitHub actions and ChatGPT is essentially a must for me since my bash +> is remedial at best. + +Then you might like Kevin Ushey's configure +, which is like autoconf +redone in R. The only few lines of bash are the system-specific bits in +{configure,cleanup}{.win,} to run the R scripts under tools/, and they +are already written for you. + +Generating two system-specific configures from one configure.ac might +be possible - GNU m4 is very versatile - but to implement that, you +would have to program m4, which is even more niche than bash. + +> The requirement to avoid GitHub feels surprisingly anachronistic +> given how central it is to the vast majority of software development. + +I think that Ben Bolker's answer explains it very well. Part of the +goal of the CRAN archive is to be able to take a package, a +period-appropriate version of R and install the former on the latter. +The URL carrying the code must be able to survive as long. Unlike +Zenodo, GitHub's goal is not directly to provide storage forever, and +its current owners have a reputation [*] that could have played a part +in the requirement to avoid them. + +I wonder if it would be ethical to use Archive.org for this. + +In an ideal world, CRAN would be able to directly archive larger +software packages (just like PyPI is currently hosting more than a +terabyte of Tensorflow builds and a few terabytes more of other +GPU-related code [**]) without requiring the maintainers to swim +between the Scylla of vendoring the dependencies and the Charybdis of +making the build depend on an external URL, but that's a luxury someone +would have to pay for. + +-- +Best regards, +Ivan + +[*] +https://stat.ethz.ch/pipermail/r-package-devel/2024q2/010708.html + +[**] +https://discuss.python.org/t/what-to-do-about-gpus-and-the-built-distributions-that-support-them/7125/16 + + +From edd @end|ng |rom deb|@n@org Thu May 9 19:21:42 2024 +From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel) +Date: Thu, 9 May 2024 12:21:42 -0500 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: <20240509200721.2209bad4@Tarkus> +References: + + + <20240508223200.4d659fe4@Tarkus> + + <20240509200721.2209bad4@Tarkus> +Message-ID: <26173.1574.43304.738024@rob.eddelbuettel.com> + + +Software Heritage (see [1] for their website and [2] for a brief intro I gave +at useR! 2019 in Toulouse) covers GitHub and CRAN [3]. It is by now 'in +collaboration with UNESCO', supported by a long and posh list of sponsors [4] +and about as good as it gets to 'ensure longevity of artifacts'. + +It is of course not meant for downloads during frequent builds. + +But given the 'quasi-institutional nature' and sponsorship, we could think of +using GitHub as an 'active cache'. But CRAN is CRAN and as it now stands +GitHub is not trusted. ?\_(?)_/? + +Dirk + + +[1] https://www.softwareheritage.org/ +[2] https://dirk.eddelbuettel.com/papers/useR2019_swh_cran_talk.pdf +[3] https://www.softwareheritage.org/faq/ question 2.1 +[4] https://www.softwareheritage.org/support/sponsors/ +-- +dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org + + +From jo@|@h@p@rry @end|ng |rom gm@||@com Thu May 9 20:29:29 2024 +From: jo@|@h@p@rry @end|ng |rom gm@||@com (Josiah Parry) +Date: Thu, 9 May 2024 14:29:29 -0400 +Subject: [R-pkg-devel] Overcoming CRAN's 5mb vendoring requirement +In-Reply-To: <26173.1574.43304.738024@rob.eddelbuettel.com> +References: + + + <20240508223200.4d659fe4@Tarkus> + + <20240509200721.2209bad4@Tarkus> + <26173.1574.43304.738024@rob.eddelbuettel.com> +Message-ID: + +> +> ...but that's a luxury someone would have to pay for. +> + +I'd happily give up my Netflix subscription for this. I suspect the +R-foundation/consortium could assist as well? + +Referring to the "Using Rust in CRAN packages" document we must be able to + +...download a specific version from a secure and reliable site + + +but, as far as I can tell, there is no definition of "secure" or "reliable" +or examples of these. +Is there a specification of availability / uptime for the site? Or +otherwise. + +*What venues do we have for working on this issue in a formal manner?* + +I think that these small issues add up and really do hamper the ability for +R to grow as a language. +Talented developers (that adjective does not apply to myself) spend *a lot* of +time trying to resolve +these issues. And too many (one is too many) have given up on CRAN and +consequently their +contributions to R have dwindled. + +There are a number of really great tools that have to handle this +independently (arrow R packages and DuckDB +are good examples) but they have teams and funding behind them. If the bar +is going to be so high to publish +a package, we need to at least make a ladder (tools, packages, templates +etc) to get there. + + +---- + + https://cran.r-project.org/web/packages/using_rust.html + + + + +On Thu, May 9, 2024 at 1:21?PM Dirk Eddelbuettel wrote: + +> +> Software Heritage (see [1] for their website and [2] for a brief intro I +> gave +> at useR! 2019 in Toulouse) covers GitHub and CRAN [3]. It is by now 'in +> collaboration with UNESCO', supported by a long and posh list of sponsors +> [4] +> and about as good as it gets to 'ensure longevity of artifacts'. +> +> It is of course not meant for downloads during frequent builds. +> +> But given the 'quasi-institutional nature' and sponsorship, we could think +> of +> using GitHub as an 'active cache'. But CRAN is CRAN and as it now stands +> GitHub is not trusted. ?\_(?)_/? +> +> Dirk +> +> +> [1] https://www.softwareheritage.org/ +> [2] https://dirk.eddelbuettel.com/papers/useR2019_swh_cran_talk.pdf +> [3] https://www.softwareheritage.org/faq/ question 2.1 +> [4] https://www.softwareheritage.org/support/sponsors/ +> -- +> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org +> + + [[alternative HTML version deleted]] + + +From @|mon@urb@nek @end|ng |rom R-project@org Fri May 10 00:45:44 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Fri, 10 May 2024 10:45:44 +1200 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: + +Message-ID: <82807F66-5421-4C62-ADB0-6B60B17BCA14@R-project.org> + + + +> On 9/05/2024, at 11:58 PM, Vladimir Dergachev wrote: +> +> +> +> On Thu, 9 May 2024, Sameh Abdulah wrote: +> +>> Hi, +>> +>> I need to serialize and save a 20K x 20K matrix as a binary file. This process is significantly slower in R compared to Python (4X slower). +>> +>> I'm not sure about the best approach to optimize the below code. Is it possible to parallelize the serialization function to enhance performance? +> +> Parallelization should not help - a single CPU thread should be able to saturate your disk or your network, assuming you have a typical computer. +> +> The problem is possibly the conversion to text, writing it as binary should be much faster. +> + + +FWIW serialize() is binary so there is no conversion to text: + +> serialize(1:10+0L, NULL) + [1] 58 0a 00 00 00 03 00 04 02 00 00 03 05 00 00 00 00 05 55 54 46 2d 38 00 00 +[26] 00 0d 00 00 00 0a 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 +[51] 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 0a + +It uses the native representation so it is actually not as bad as it sounds. + +One aspect I forgot to mention in the earlier thread is that if you don't need to exchange the serialized objects between machines with different endianness then avoiding the swap makes it faster. E.g, on Intel (which is little-endian and thus needs swapping): + +> a=1:1e8/2 +> system.time(serialize(a, NULL)) + user system elapsed + 2.123 0.468 2.661 +> system.time(serialize(a, NULL, xdr=FALSE)) + user system elapsed + 0.393 0.348 0.742 + +Cheers, +Simon + + +From henr|k@bengt@@on @end|ng |rom gm@||@com Fri May 10 02:31:06 2024 +From: henr|k@bengt@@on @end|ng |rom gm@||@com (Henrik Bengtsson) +Date: Thu, 9 May 2024 17:31:06 -0700 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: <82807F66-5421-4C62-ADB0-6B60B17BCA14@R-project.org> +References: + + <82807F66-5421-4C62-ADB0-6B60B17BCA14@R-project.org> +Message-ID: + +On Thu, May 9, 2024 at 3:46?PM Simon Urbanek + wrote: +> +> +> +> > On 9/05/2024, at 11:58 PM, Vladimir Dergachev wrote: +> > +> > +> > +> > On Thu, 9 May 2024, Sameh Abdulah wrote: +> > +> >> Hi, +> >> +> >> I need to serialize and save a 20K x 20K matrix as a binary file. This process is significantly slower in R compared to Python (4X slower). +> >> +> >> I'm not sure about the best approach to optimize the below code. Is it possible to parallelize the serialization function to enhance performance? +> > +> > Parallelization should not help - a single CPU thread should be able to saturate your disk or your network, assuming you have a typical computer. +> > +> > The problem is possibly the conversion to text, writing it as binary should be much faster. +> > +> +> +> FWIW serialize() is binary so there is no conversion to text: +> +> > serialize(1:10+0L, NULL) +> [1] 58 0a 00 00 00 03 00 04 02 00 00 03 05 00 00 00 00 05 55 54 46 2d 38 00 00 +> [26] 00 0d 00 00 00 0a 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 +> [51] 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 0a +> +> It uses the native representation so it is actually not as bad as it sounds. +> +> One aspect I forgot to mention in the earlier thread is that if you don't need to exchange the serialized objects between machines with different endianness then avoiding the swap makes it faster. E.g, on Intel (which is little-endian and thus needs swapping): +> +> > a=1:1e8/2 +> > system.time(serialize(a, NULL)) +> user system elapsed +> 2.123 0.468 2.661 +> > system.time(serialize(a, NULL, xdr=FALSE)) +> user system elapsed +> 0.393 0.348 0.742 + +Would it be worth looking into making xdr=FALSE the default? From +help("serialize"): + +xdr: a logical: if a binary representation is used, should a +big-endian one (XDR) be used? +... +As almost all systems in current use are little-endian, xdr = FALSE +can be used to avoid byte-shuffling at both ends when transferring +data from one little-endian machine to another (or between processes +on the same machine). Depending on the system, this can speed up +serialization and unserialization by a factor of up to 3x. + +This seems like a low-hanging fruit that could spare the world from +wasting unnecessary CPU cycles. + +/Henrik + + + +> +> Cheers, +> Simon +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From @|mon@urb@nek @end|ng |rom R-project@org Fri May 10 05:12:17 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Fri, 10 May 2024 15:12:17 +1200 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: + + <82807F66-5421-4C62-ADB0-6B60B17BCA14@R-project.org> + +Message-ID: + + + +> On 10/05/2024, at 12:31 PM, Henrik Bengtsson wrote: +> +> On Thu, May 9, 2024 at 3:46?PM Simon Urbanek +> wrote: +>> +>> FWIW serialize() is binary so there is no conversion to text: +>> +>>> serialize(1:10+0L, NULL) +>> [1] 58 0a 00 00 00 03 00 04 02 00 00 03 05 00 00 00 00 05 55 54 46 2d 38 00 00 +>> [26] 00 0d 00 00 00 0a 00 00 00 01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 +>> [51] 05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00 09 00 00 00 0a +>> +>> It uses the native representation so it is actually not as bad as it sounds. +>> +>> One aspect I forgot to mention in the earlier thread is that if you don't need to exchange the serialized objects between machines with different endianness then avoiding the swap makes it faster. E.g, on Intel (which is little-endian and thus needs swapping): +>> +>>> a=1:1e8/2 +>>> system.time(serialize(a, NULL)) +>> user system elapsed +>> 2.123 0.468 2.661 +>>> system.time(serialize(a, NULL, xdr=FALSE)) +>> user system elapsed +>> 0.393 0.348 0.742 +> +> Would it be worth looking into making xdr=FALSE the default? From +> help("serialize"): +> +> xdr: a logical: if a binary representation is used, should a +> big-endian one (XDR) be used? +> ... +> As almost all systems in current use are little-endian, xdr = FALSE +> can be used to avoid byte-shuffling at both ends when transferring +> data from one little-endian machine to another (or between processes +> on the same machine). Depending on the system, this can speed up +> serialization and unserialization by a factor of up to 3x. +> +> This seems like a low-hanging fruit that could spare the world from +> wasting unnecessary CPU cycles. +> + + +I thought about it before, but the main problem here is (as often) compatibility. The current default guarantees that the output can be safely read on any machine while xdr=FALSE only works if used on machines with the same endianness and will fail horribly otherwise. R cannot really know whether the user intends to transport the serialized data to another machine or not, so it cannot assume it is safe unless the user indicates so. Therefore all we can safely do is tell the users that they should use it where appropriate -- and the documentation explicitly says so: + + As almost all systems in current use are little-endian, ?xdr = + FALSE? can be used to avoid byte-shuffling at both ends when + transferring data from one little-endian machine to another (or + between processes on the same machine). Depending on the system, + this can speed up serialization and unserialization by a factor of + up to 3x. + +Unfortunately, no one bothers to reads the documentation so it is not as effective as changing the default, but for reasons above it is just not as easy to change. I do acknowledge that the risk is relatively low since big-endian machines are becoming rare, but it's not zero. + +That said, what worries me a bit more is that some derived functions such as saveRDS() don't expose the xdr option, so you actually have no way to use the native binary format. I understand the logic - see above, but as you said, that makes them unnecessarily slow. I wonder if it may be worth doing something a bit smarter and tag officially a "reverse XDR" format instead - that way it would be well-defined and could be made the default. Interestingly, the de-serialization part actually doesn't care, so you can use readRDS() on the binary serialization even in current R versions, so just adding the option would still be backwards-compatible. Definitely something to think about... + +Cheers, +Simon + + +> +> +>> +>> Cheers, +>> Simon +>> +>> ______________________________________________ +>> R-package-devel at r-project.org mailing list +>> https://stat.ethz.ch/mailman/listinfo/r-package-devel +> + + +From othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com Fri May 10 08:04:16 2024 +From: othm@n@e|@h@mmouch| @end|ng |rom protonm@||@com (Othman El Hammouchi) +Date: Fri, 10 May 2024 06:04:16 +0000 +Subject: [R-pkg-devel] flang doesn't support derived types +In-Reply-To: <20240509193430.1998b917@Tarkus> +References: <6ffdcf71-8ebf-4af3-ac53-fc166092b07b@protonmail.com> + <20240509174101.0c7edfd9@trisector> + + <20240509193430.1998b917@Tarkus> +Message-ID: <56070879-a6bb-4e7d-8454-f1145085625f@protonmail.com> + +Dear Ivan, + + +Thanks again for the help, you've given me some great pointers to +pursue. I will keep you posted on what CRAN responds and whether I find +a workaround. + + > I do wish that flang-new would be a better compiler or at least a + > better documented one, but instead of a list of features on their + > website, I can only see "Getting Involved [3] for tips on how to get in + > touch <...> and to learn more about the current status". There is only + > so many projects one can get involved in. + +The problem is not the quality of the compiler so much as the fact that +it's not finished. They don't make a big secret of the fact that it's +still under development. It may be the standard in industry as you say, +but it would greatly surprise me if it was the default for most ordinary +users. Most distros and platforms seem to ship the (much more complete) +gfortran. + + +Yours, + + +Othman El Hammouchi + +On 09/05/2024 18:34, Ivan Krylov wrote: +> ? Thu, 09 May 2024 15:31:25 +0000 +> Othman El Hammouchi ?????: +> +>> Do I understand it correctly that there is no way to specify a +>> Fortran standard in the SystemRequirements? +> It's possible (and even recommended) to describe the Fortran version +> requirement in SystemRequirements [1], but this field is for now mostly +> informational. I think I remember efforts to standardise it, but they +> are far from complete. +> +>> I had resubmitted my package in the mean time with a configure script +>> that aborts the install if the compiler does not support +>> polymorphism, but I understand that this is a fruitless avenue for +>> CRAN? +> Signs point to yes, at least judging by a previous time we had +> flang-related problems [2]. On the other hand, there were relatively +> easy workarounds that time, and here I'm not seeing anything as simple. +> +>> I should point out my local flang install is version 16, but I cannot +>> install 18 on my system since it's in unstable (this again +>> underscores the problem of developing under these constraints). +> Would you consider containers for this purpose? I was able to reproduce +> the problem relatively quickly by starting podman run --rm -it +> debian:sid and installing flang-18 in there. (Unlike Docker a few years +> ago, podman can be installed straight from the repository, at least on +> Debian, and doesn't require adding users to special groups in order to +> work. Maybe Docker has also improved.) I don't like containers as a +> basis for software distribution, but I can't deny that they are being +> great at letting me quickly reproduce problems without installing 10 +> different GNU/Linux distros. +> +>> What would you advise? And don't you think these Fortran constraints +>> should be better documenten. +> I'm afraid I don't have any more specific advice besides testing your +> workarounds with Debian Sid in a container or a virtual machine or a +> chroot. I can try to take a look at more concrete problems. I hope you +> will be able to find a relatively painless workaround. +> +> I do wish that flang-new would be a better compiler or at least a +> better documented one, but instead of a list of features on their +> website, I can only see "Getting Involved [3] for tips on how to get in +> touch <...> and to learn more about the current status". There is only +> so many projects one can get involved in. +> +> -- +> Best regards, +> Ivan +> +> [1] +> https://cran.r-project.org/doc/manuals/R-exts.html#Using-modern-Fortran-code +> +> [2] +> https://stat.ethz.ch/pipermail/r-package-devel/2023q4/010065.html +> +> [3] +> https://flang.llvm.org/docs/GettingInvolved.html + + +From |kry|ov @end|ng |rom d|@root@org Fri May 10 17:38:43 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Fri, 10 May 2024 18:38:43 +0300 +Subject: [R-pkg-devel] Fast Matrix Serialization in R? +In-Reply-To: +References: + + <82807F66-5421-4C62-ADB0-6B60B17BCA14@R-project.org> + + +Message-ID: <20240510183843.5c60cfe1@Tarkus> + +On Fri, 10 May 2024 15:12:17 +1200 +Simon Urbanek wrote: + +> I wonder if it may be worth doing something a bit smarter and tag +> officially a "reverse XDR" format instead - that way it would be +> well-defined and could be made the default. + +Do you mean changing R so that when reading a "B\n" serialized stream, +a format code read as 0x02000000 or 0x03000000 would mean regular +formats 2 or 3 but byte-swapped? That would be backwards-compatible, +and we probably weren't going to have >= 65536 format versions anyway... + +-- +Best regards, +Ivan + + +From k@||eng|u @end|ng |rom gm@||@com Sun May 12 20:43:18 2024 +From: k@||eng|u @end|ng |rom gm@||@com (Kaifeng Lu) +Date: Sun, 12 May 2024 14:43:18 -0400 +Subject: [R-pkg-devel] clang-UBSAN +Message-ID: + +Dear friends, + +I am developing an R package built with Rcpp. The package passed the test +with devtools::check() before submission to CRAN, but failed with the +following clang-UBSAN issue after submission to CRAN: + +/data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25: +runtime error: nan is outside the range of representable values of type +'int' + +Is there any way to reproduce the error before submitting the package to +CRAN? + +Thank you very much for helping! + +Regards, +Kaifeng + + [[alternative HTML version deleted]] + + +From @|mon@urb@nek @end|ng |rom R-project@org Mon May 13 00:46:56 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Mon, 13 May 2024 10:46:56 +1200 +Subject: [R-pkg-devel] + Trouble with dependencies on phyloseq and microViz +In-Reply-To: +References: <1FB885FF-2DA6-4CB6-A987-38858C3AF7FA@clemson.edu> + <20240504193210.0332d714@Tarkus> + <7205534A-6666-4EDE-B613-68AAAFED2F2D@R-project.org> + <20240507091552.090ad6ec@Tarkus> + +Message-ID: + +Sharon, + +I have upgraded Bioc on the R-oldrel build machines and that seems to have taken care of the problem as far as I can tell: +https://cran.r-project.org/web/checks/check_results_HybridMicrobiomes.html + +If you have reports like that, it's a better idea to ask us first and always supply the name of the package, otherwise the thread can quickly degrade to wild guesswork and misleading or incorrect answers from unrelated parties. + +Cheers, +Simon + + +> On 7/05/2024, at 6:56 PM, Simon Urbanek wrote: +> +> Ivan, +> +> sorry if it wasn't clear, but this thread was about strong dependencies -- Sharon noted that phyloseq must remain strong dependency and asked how to deal with that (see all the parts you cut from this thread). Now that I finally have the package name I can check the details - apparently this only affects R-oldrel so presumable Bioc upgrade may fix this so I'll have a look tomorrow. +> +> Cheers, +> Simon +> + + +From |kry|ov @end|ng |rom d|@root@org Mon May 13 09:03:21 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Mon, 13 May 2024 10:03:21 +0300 +Subject: [R-pkg-devel] clang-UBSAN +In-Reply-To: +References: +Message-ID: <20240513100321.297ae1da@Tarkus> + +? Sun, 12 May 2024 14:43:18 -0400 +Kaifeng Lu ?????: + +> /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25: +> runtime error: nan is outside the range of representable values of +> type 'int' + +On line 4618 of src/misc.cpp of the lrstat package, you have a +suspicious default parameter value: + +>> const int n = NA_REAL + +NA_REAL is a special kind of NaN, and C++ signed integers cannot +represent NaNs. You probably meant NA_INTEGER. + +I think that Rcpp::traits::input_parameter takes care of +asking R to cast NA_REAL to NA_INTEGER, so this shouldn't directly +cause problems, but without a link to the code and the full error +report we have to resort to forbidden OSINT techniques [1], which don't +always work reliably and may attract the wrong kind of attention on the +darknet [2]. + +> Is there any way to reproduce the error before submitting the package +> to CRAN? + +Yes. + +If you use containers, try the rocker/r-devel-ubsan-clang [3] image +that should already contain a "sanitized" build of R produced with the +clang compiler. + +If that doesn't help, start with a Fedoda 36 installation and follow +the description [4] to install clang and compile R from source with +sanitizers enabled. This procedure is described in more detail in WRE +4.3.4 [5]. + +If you start having problems using the Docker/podman image or compiling +R from source, don't hesitate to ask further questions. + +-- +Best regards, +Ivan + +[1] +Such as searching your name on CRAN and GitHub. + +[2] +Such as Google suggesting AI-powered results. + +[3] +https://rocker-project.org/images/ + +[4] +https://www.stats.ox.ac.uk/pub/bdr/memtests/README.txt + +[5] +https://cran.r-project.org/doc/manuals/R-exts.html#Using-Undefined-Behaviour-Sanitizer + + +From c@@rd|@g@bor @end|ng |rom gm@||@com Mon May 13 09:24:20 2024 +From: c@@rd|@g@bor @end|ng |rom gm@||@com (=?UTF-8?B?R8OhYm9yIENzw6FyZGk=?=) +Date: Mon, 13 May 2024 09:24:20 +0200 +Subject: [R-pkg-devel] clang-UBSAN +In-Reply-To: +References: +Message-ID: + +The rhub package should be able to reproduce that, see +https://github.com/r-hub/rhub#readme + +Or you can use the clang-asan container directly: +https://r-hub.github.io/containers/ + +Gabor + +On Mon, May 13, 2024 at 12:31?AM Kaifeng Lu wrote: +> +> Dear friends, +> +> I am developing an R package built with Rcpp. The package passed the test +> with devtools::check() before submission to CRAN, but failed with the +> following clang-UBSAN issue after submission to CRAN: +> +> /data/gannet/ripley/R/test-clang/Rcpp/include/Rcpp/internal/caster.h:30:25: +> runtime error: nan is outside the range of representable values of type +> 'int' +> +> Is there any way to reproduce the error before submitting the package to +> CRAN? +> +> Thank you very much for helping! +> +> Regards, +> Kaifeng +> +> [[alternative HTML version deleted]] +> +> ______________________________________________ +> R-package-devel at r-project.org mailing list +> https://stat.ethz.ch/mailman/listinfo/r-package-devel + + +From ruw@n|r@@@nj@||h @end|ng |rom gm@||@com Mon May 13 15:33:04 2024 +From: ruw@n|r@@@nj@||h @end|ng |rom gm@||@com (Ruwani Herath) +Date: Mon, 13 May 2024 08:33:04 -0500 +Subject: [R-pkg-devel] An issue regarding the authors field in DESCRIPTION +Message-ID: + +Hi, +I have submitted an R package and I got the following notes from the CRAN +test. I couldn't find what should be the change I have to do to correct +this issue. Please check this and guide me to solve the issue. + +* checking CRAN incoming feasibility ... NOTE +Maintainer: 'Ruwani Herath ' + +* checking DESCRIPTION meta-information ... NOTE + +Author field differs from that derived from Authors at R + Author: 'Ruwani Herath [aut,cre,cph,com], Leila Amiri [ctb], +Mahmoud Torabi [ctb]' + Authors at R: 'Ruwani Herath [aut, cre, cph, com], Leila Amiri [ctb], +Mahmoud Torabi [ctb]' + + +This is what I entered in DESCRIPTION field. + +Authors at R: c(person(given = "Ruwani", family = "Herath", role = c("aut","cre"), + email = "ruwanirasanjalih at gmail.com"), + person(given = "Leila", family = "Amiri", role = "ctb"), + person(given = "Mahmoud", family = "Torabi", role = "ctb")) + +Authors: Ruwani Herath [aut, cre], + Leila Amiri [ctb], + Mahmoud Torabi [ctb] +Maintainer: Ruwani Herath + + +Thank you. + +Regards, + +Ruwani + + [[alternative HTML version deleted]] + + +From |kry|ov @end|ng |rom d|@root@org Mon May 13 15:54:08 2024 +From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov) +Date: Mon, 13 May 2024 16:54:08 +0300 +Subject: [R-pkg-devel] + An issue regarding the authors field in DESCRIPTION +In-Reply-To: +References: +Message-ID: <20240513165408.460c1e79@arachnoid> + +? Mon, 13 May 2024 08:33:04 -0500 +Ruwani Herath ?????: + +> This is what I entered in DESCRIPTION field. +> +> Authors at R: c(person(given = "Ruwani", family = "Herath", role = +> c("aut","cre"), email = "ruwanirasanjalih at gmail.com"), +> person(given = "Leila", family = "Amiri", role = "ctb"), +> person(given = "Mahmoud", family = "Torabi", role = +> "ctb")) +> +> Authors: Ruwani Herath [aut, cre], +> Leila Amiri [ctb], +> Mahmoud Torabi [ctb] +> Maintainer: Ruwani Herath + +R CMD build generates the fields "Authors" and "Maintainers" from the +field "Authors at R", so the easiest way forward is to delete Authors: and +Maintainer: from your DESCRIPTION. Next time you run R CMD build, the +DESCRIPTION file inside the resulting *.tar.gz file will contain the +correct fields "Authors" and "Maintainers". + +-- +Best regards, +Ivan + + diff --git a/r-sig-mac/2024-April.txt b/r-sig-mac/2024-April.txt new file mode 100644 index 0000000..b98f55f --- /dev/null +++ b/r-sig-mac/2024-April.txt @@ -0,0 +1,2202 @@ +From h@nne@ @end|ng |rom duckdb|@b@@com Thu Apr 4 09:47:00 2024 +From: h@nne@ @end|ng |rom duckdb|@b@@com (=?UTF-8?Q?Hannes_M=C3=BChleisen?=) +Date: Thu, 4 Apr 2024 09:47:00 +0200 +Subject: [R-SIG-Mac] Debugging Symbols +Message-ID: + +Hello List, + +we would like to bring up the topic of debug symbols in the CRAN OSX +binaries again. I realize this has been discussed before [1] and +realize the symbols are there for a reason, but in the duckdb package +their inclusion is particularly problematic. + +Currently, the CRAN binary for OSX Arm64 weighs in at a whopping 97 MB +[2]. Inside it lives a 311 MB (uncompressed) folder with the debugging +symbols. When I remove the debugging symbols and re-create the +compressed tarball, its compressed size goes down to 11 MB, a pretty +drastic difference. + +We are getting feedback from users that the package is too large for +them to be useful, so we would really like to improve this situation. + +Would it perhaps be possible to exclude the duckdb from the inclusion +of the debug symbols? Is there anything we as package authors can do +here? There also may be other packages where this is relevant, e.g. +arrow would go down from 82 MB to 12 MB. + +Best and thanks + +Hannes + +[1] https://stat.ethz.ch/pipermail/r-sig-mac/2022-June/014500.html +[2] curl -I https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.3/duckdb_0.10.1.tgz + + +From jeroenoom@ @end|ng |rom gm@||@com Thu Apr 4 10:41:55 2024 +From: jeroenoom@ @end|ng |rom gm@||@com (Jeroen Ooms) +Date: Thu, 4 Apr 2024 10:41:55 +0200 +Subject: [R-SIG-Mac] Debugging Symbols +In-Reply-To: +References: +Message-ID: + +On Thu, Apr 4, 2024 at 9:47?AM Hannes M?hleisen wrote: +> +> Hello List, +> +> we would like to bring up the topic of debug symbols in the CRAN OSX +> binaries again. I realize this has been discussed before [1] and +> realize the symbols are there for a reason, but in the duckdb package +> their inclusion is particularly problematic. +> +> Currently, the CRAN binary for OSX Arm64 weighs in at a whopping 97 MB +> [2]. Inside it lives a 311 MB (uncompressed) folder with the debugging +> symbols. When I remove the debugging symbols and re-create the +> compressed tarball, its compressed size goes down to 11 MB, a pretty +> drastic difference. +> +> We are getting feedback from users that the package is too large for +> them to be useful, so we would really like to improve this situation. + +FWIW, the binaries on https://duckdb.r-universe.dev/duckdb are built +with _R_SHLIB_STRIP_: TRUE and those are indeed around 10M (both for +Linux and MacOS). + +For similar reasons p3m (formerly rspm) also strips debugging symbols +these days, e.g: +https://p3m.dev/cran/latest/bin/macosx/big-sur-x86_64/contrib/4.3/duckdb_0.10.1.tgz +See also this comment: +https://github.com/rocker-org/rocker-versioned2/issues/340#issuecomment-1301157428 + +I agree it would be nice for a package to be able to opt-out +altogether, including on CRAN. I don't think that is possible right +now. + + +From gp@ct @end|ng |rom proton@me Thu Apr 4 15:13:24 2024 +From: gp@ct @end|ng |rom proton@me (Gregory) +Date: Thu, 04 Apr 2024 13:13:24 +0000 +Subject: [R-SIG-Mac] How to correct tcltk path? +Message-ID: + +Hello, + +I'm having an issue with R looking for tcltk in the wrong place. Whenever I start R, I get a message: tcltk DLL is linked to '/opt/X11/lib/libX11.6.dylib'. However, there is no /opt/X11 on my system and tcltk is really in /opt/R/arm64, where the R binary installer put it. Where is R getting the /opt/X11 path and how do I correct that? So far I've tried exporting DYLD_LIBRARY_PATH=opt/R/arm64:$DYLD_LIBRARY_PATH to my environment in my zprofile, but that hasn't worked. + +Possibly relevant details: +M2 MacBook Pro, MacOS Sonoma 14.4.1 +R.version 4.3.3 installed with binary installer from CRAN. + +Thanks in advance, +Gregory + +Sent with [Proton Mail](https://proton.me/) secure email. + [[alternative HTML version deleted]] + + +From k@@perd@n|e|h@n@en @end|ng |rom gm@||@com Thu Apr 4 18:46:38 2024 +From: k@@perd@n|e|h@n@en @end|ng |rom gm@||@com (Kasper Daniel Hansen) +Date: Thu, 4 Apr 2024 12:46:38 -0400 +Subject: [R-SIG-Mac] How to correct tcltk path? +In-Reply-To: +References: +Message-ID: + +You need to install XQuartz. This is IMO stated somewhat clearly at + https://cran.r-project.org/bin/macosx/ +("somewhat", because - as always - it seems pretty clear when you know what +its trying to say) + +Kasper + +On Thu, Apr 4, 2024 at 9:13?AM Gregory via R-SIG-Mac < +r-sig-mac at r-project.org> wrote: + +> Hello, +> +> I'm having an issue with R looking for tcltk in the wrong place. Whenever +> I start R, I get a message: tcltk DLL is linked to +> '/opt/X11/lib/libX11.6.dylib'. However, there is no /opt/X11 on my system +> and tcltk is really in /opt/R/arm64, where the R binary installer put it. +> Where is R getting the /opt/X11 path and how do I correct that? So far I've +> tried exporting DYLD_LIBRARY_PATH=opt/R/arm64:$DYLD_LIBRARY_PATH to my +> environment in my zprofile, but that hasn't worked. +> +> Possibly relevant details: +> M2 MacBook Pro, MacOS Sonoma 14.4.1 +> R.version 4.3.3 installed with binary installer from CRAN. +> +> Thanks in advance, +> Gregory +> +> Sent with [Proton Mail](https://proton.me/) secure email. +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac +> + + +-- +Best, +Kasper + + [[alternative HTML version deleted]] + + +From r|p|ey @end|ng |rom @t@t@@ox@@c@uk Thu Apr 4 19:26:20 2024 +From: r|p|ey @end|ng |rom @t@t@@ox@@c@uk (Prof Brian Ripley) +Date: Thu, 4 Apr 2024 18:26:20 +0100 +Subject: [R-SIG-Mac] How to correct tcltk path? +In-Reply-To: +References: + +Message-ID: + +On 04/04/2024 17:46, Kasper Daniel Hansen wrote: +> You need to install XQuartz. This is IMO stated somewhat clearly at +> https://cran.r-project.org/bin/macosx/ +> ("somewhat", because - as always - it seems pretty clear when you know what +> its trying to say) + +And definitely clear in the R-admin manual: + +"Various parts of the build require XQuartz to be installed: see +https://www.xquartz.org/releases/.20 These include the tcltk package and +the X11 graphics device: attempting to use these without XQuartz will +remind you." + +Without the actual messages, I cannot check if that corresponds to what +the OP saw. But it probably was from + + message("tcltk DLL is linked to ", shQuote(this)) + stop("X11 library is missing: install XQuartz from +www.xquartz.org", + +and he omitted the second line .... + + + +> +> Kasper +> +> On Thu, Apr 4, 2024 at 9:13?AM Gregory via R-SIG-Mac < +> r-sig-mac at r-project.org> wrote: +> +>> Hello, +>> +>> I'm having an issue with R looking for tcltk in the wrong place. Whenever +>> I start R, I get a message: tcltk DLL is linked to +>> '/opt/X11/lib/libX11.6.dylib'. However, there is no /opt/X11 on my system +>> and tcltk is really in /opt/R/arm64, where the R binary installer put it. +>> Where is R getting the /opt/X11 path and how do I correct that? So far I've +>> tried exporting DYLD_LIBRARY_PATH=opt/R/arm64:$DYLD_LIBRARY_PATH to my +>> environment in my zprofile, but that hasn't worked. +>> +>> Possibly relevant details: +>> M2 MacBook Pro, MacOS Sonoma 14.4.1 +>> R.version 4.3.3 installed with binary installer from CRAN. +>> +>> Thanks in advance, +>> Gregory +>> +>> Sent with [Proton Mail](https://proton.me/) secure email. +>> [[alternative HTML version deleted]] +>> +>> _______________________________________________ +>> R-SIG-Mac mailing list +>> R-SIG-Mac at r-project.org +>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac +>> +> +> + +-- +Brian D. Ripley, ripley at stats.ox.ac.uk +Emeritus Professor of Applied Statistics, University of Oxford + + +From ce||ocgw @end|ng |rom gm@||@com Tue Apr 30 00:55:38 2024 +From: ce||ocgw @end|ng |rom gm@||@com (Carl Witthoft) +Date: Mon, 29 Apr 2024 18:55:38 -0400 +Subject: [R-SIG-Mac] R 4.4 crashes loading dplyr +Message-ID: + +I apologize if the file posted below is the wrong log. +I start up R 4.4.0 on my iMac 13.5.2 , type 'library(dplyr)' and r.app +gui crashes immediately. Same for ggplot2, gert, stringr, and others . + + I have verified that I've updated every R library in my system. I can +successfully load other libs, e.g., Rmpfr,knitr, MASS, so I doubt it's a +directory or permissions problem. + +From the command line: + library(dplyr) + + *** caught segfault *** +address 0x406e0, cause 'memory not mapped' + +Traceback: + 1: fun(libname, pkgname) + 2: doTryCatch(return(expr), name, parentenv, handler) + 3: tryCatchOne(expr, names, parentenv, handlers[[1L]]) + 4: tryCatchList(expr, classes, parentenv, handlers) + 5: tryCatch(fun(libname, pkgname), error = identity) + 6: runHook(".onLoad", env, package.lib, package) + 7: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = +vI[[j]]) + 8: asNamespace(ns) + 9: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc, +.libPaths()), versionCheck = vI[[j]]), i[[2L]], from = package) +10: loadNamespace(package, lib.loc) +11: doTryCatch(return(expr), name, parentenv, handler) +12: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +13: tryCatchList(expr, classes, parentenv, handlers) +14: tryCatch({ attr(package, "LibPath") <- which.lib.loc ns <- +loadNamespace(package, lib.loc) env <- attachNamespace(ns, pos = pos, +deps, exclude, include.only)}, error = function(e) { P <- if +(!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L]) +else "" msg <- gettextf("package or namespace load failed for %s%s:\n +%s", sQuote(package), P, conditionMessage(e)) if (logical.return +&& !quietly) message(paste("Error:", msg), domain = NA) else +stop(msg, call. = FALSE, domain = NA)}) +15: library(dplyr) + + + +---- ~/library/logs/diagnosticreports file pasted below -- + +{"app_name":"R","timestamp":"2024-04-29 11:11:39.00 -0400","app_version":"R +4.4.0 GUI 1.80 Big Sur Intel +build","slice_uuid":"8311af3a-aa38-355b-acef-bbecbdb69a11","build_version":"8376","platform":1,"bundleID":"org.R-project.R","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS +13.5.2 +(22G91)","roots_installed":0,"name":"R","incident_id":"059EF229-5343-4EE7-9843-B88A513B8019"} + +{ + "uptime" : 260000, + "procRole" : "Foreground", + "version" : 2, + "userID" : 502, + "deployVersion" : 210, + "modelCode" : "iMac19,2", + "coalitionID" : 1308, + "osVersion" : { + "train" : "macOS 13.5.2", + "build" : "22G91", + "releaseType" : "User" + }, + "captureTime" : "2024-04-29 11:11:38.8062 -0400", + "incident" : "059EF229-5343-4EE7-9843-B88A513B8019", + "pid" : 55298, + "cpuType" : "X86-64", + "roots_installed" : 0, + "bug_type" : "309", + "procLaunch" : "2024-04-29 11:10:04.6528 -0400", + "procStartAbsTime" : 261494660416425, + "procExitAbsTime" : 261588804970703, + "procName" : "R", + "procPath" : "\/Applications\/R.app\/Contents\/MacOS\/R", + "bundleInfo" : {"CFBundleShortVersionString":"R 4.4.0 GUI 1.80 Big Sur +Intel +build","CFBundleVersion":"8376","CFBundleIdentifier":"org.R-project.R"}, + "storeInfo" : +{"deviceIdentifierForVendor":"415552B1-5065-5FAB-8DB9-7D60A9149E9E","thirdParty":true}, + + "parentProc" : "launchd", + "parentPid" : 1, + "coalitionName" : "org.R-project.R", + "crashReporterKey" : "CD7A5AA1-F53E-DB32-2D97-4F4C0CC4EC41", + "codeSigningID" : "org.R-project.R", + "codeSigningTeamID" : "VZLD955F6P", + "codeSigningFlags" : 570491653, + "codeSigningValidationCategory" : 6, + "codeSigningTrustLevel" : 0, + "wakeTime" : 1661, + "sleepWakeUUID" : "3454232B-C5AA-4B88-A913-8D5DB632B8A8", + "sip" : "enabled", + "vmRegionInfo" : "0x406e0 is not in any region. Bytes before following +region: 4486408480\n REGION TYPE START - +END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE AT +START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +SM=COW ...tents\/MacOS\/R", + "exception" : {"codes":"0x0000000000000001, +0x00000000000406e0","rawCodes":[1,263904],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS +at 0x00000000000406e0"}, + "termination" : +{"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: +11","byProc":"exc handler","byPid":55298}, + "vmregioninfo" : "0x406e0 is not in any region. Bytes before following +region: 4486408480\n REGION TYPE START - +END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE AT +START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +SM=COW ...tents\/MacOS\/R", + "extMods" : +{"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0}, + + "faultingThread" : 0, + "threads" : +[{"triggered":true,"id":2202695,"instructionState":{"instructionStream":{"bytes":[22,0,232,224,92,255,255,72,141,61,137,99,23,0,232,228,217,14,0,15,31,64,0,85,72,137,229,65,87,65,86,65,85,65,84,83,80,73,137,254,232,154,237,247,255,76,99,248,73,105,199,129,28,83,85,72,137,193,72,193,233,63,72,193,248,46,1,200,105,192,5,192,0,0,68,137,249,41,193,72,141,5,161,179,52,0,72,139,0,72,99,201,72,137,77,208,76,139,36,200,72,141,5,196,178,52,0,76,139,40,77,57,236,116,56,15,31,64,0,102,65,131,124,36,6,0,15,133,177,0,0,0,73,139,92,36,32,72,139,115,32,72,131,198,48,76,137,247,232,242,91,22,0,133,192,15,132,130,0,0,0,77,139,100,36,40,77,57,236,117,204,65,128,62,0,15,132,142,0,0,0,76,137,247,232,248,91,22,0,72,61,17],"offset":96}},"threadState":{"r13":{"value":18446744073709551608},"rax":{"value":0},"rflags":{"value":66050},"cpu":{"value":3},"r14":{"value":4937277186},"rsi":{"value":208},"r8":{"value":0},"cr2":{"value":263904},"rdx":{"value":3489660928},"r10":{"value":140468889627856},"r9":{"value":0},"r15":{"value":38277134},"rbx":{"value":1},"trap":{"value":14,"description":"(no +mapping for user data +read)"},"err":{"value":4},"r11":{"value":4499443912,"symbolLocation":0,"symbol":"R_BCProtTop"},"rip":{"value":5031094489,"matchesCrashFrame":1},"rbp":{"value":140701862106416},"rsp":{"value":140701862106368},"r12":{"sourceLine":418,"value":4937274544,"sourceFile":"pipe.c","symbol":"magrittr_init","symbolLocation":0},"rcx":{"value":32988},"flavor":"x86_THREAD_STATE","rdi":{"value":4937277200}},"queue":"com.apple.main-thread","frames":[{"imageOffset":1194201,"sourceFile":"names.c","symbol":"Rf_install","symbolLocation":73,"imageIndex":23},{"imageOffset":10802,"sourceLine":117,"sourceFile":"utils.c","symbol":"magrittr_init_utils","imageIndex":22,"symbolLocation":18},{"imageOffset":9411,"sourceLine":420,"sourceFile":"pipe.c","symbol":"magrittr_init","imageIndex":22,"symbolLocation":19},{"imageOffset":601270,"sourceLine":754,"sourceFile":"dotcode.c","symbol":"R_doDotCall","imageIndex":1,"symbolLocation":5686},{"imageOffset":1033939,"sourceLine":8691,"sourceFile":"eval.c","symbol":"bcEval_loop","imageIndex":1,"symbolLocation":146643},{"imageOffset":828276,"sourceLine":7524,"sourceFile":"eval.c","symbol":"bcEval","imageIndex":1,"symbolLocation":628},{"imageOffset":825978,"sourceLine":1167,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":506},{"imageOffset":837049,"sourceLine":2398,"sourceFile":"eval.c","symbol":"R_execClosure","imageIndex":1,"symbolLocation":761},{"imageOffset":833216,"sourceLine":2311,"sourceFile":"eval.c","symbol":"applyClosure_core","imageIndex":1,"symbolLocation":128},{"symbol":"Rf_applyClosure","inline":true,"imageIndex":1,"imageOffset":826661,"symbolLocation":24,"sourceLine":2333,"sourceFile":"eval.c"},{"imageOffset":826661,"sourceLine":1285,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":1189},{"imageOffset":1262209,"sourceLine":398,"sourceFile":"main.c","symbol":"R_ReplDLLdo1","imageIndex":1,"symbolLocation":449},{"imageOffset":125943,"symbol":"run_REngineRmainloop","symbolLocation":263,"imageIndex":0},{"imageOffset":79712,"symbol":"-[REngine +runREPL]","symbolLocation":144,"imageIndex":0},{"imageOffset":12040,"symbol":"main","symbolLocation":792,"imageIndex":0},{"imageOffset":25631,"symbol":"start","symbolLocation":1903,"imageIndex":28}]},{"id":2202741,"frames":[{"imageOffset":41618,"symbol":"__select","symbolLocation":10,"imageIndex":29},{"imageOffset":22914,"symbol":"-[RController +readThread:]","symbolLocation":642,"imageIndex":0},{"imageOffset":361987,"symbol":"__NSThread__start__","symbolLocation":1009,"imageIndex":30},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2202791,"name":"com.apple.NSEventThread","frames":[{"imageOffset":5570,"symbol":"mach_msg2_trap","symbolLocation":10,"imageIndex":29},{"imageOffset":63293,"symbol":"mach_msg2_internal","symbolLocation":78,"imageIndex":29},{"imageOffset":34292,"symbol":"mach_msg_overwrite","symbolLocation":692,"imageIndex":29},{"imageOffset":6314,"symbol":"mach_msg","symbolLocation":19,"imageIndex":29},{"imageOffset":512111,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":145,"imageIndex":32},{"imageOffset":506608,"symbol":"__CFRunLoopRun","symbolLocation":1365,"imageIndex":32},{"imageOffset":503601,"symbol":"CFRunLoopRunSpecific","symbolLocation":560,"imageIndex":32},{"imageOffset":1696757,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":33},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2203120,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203475,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203476,"frames":[{"imageOffset":16334,"symbol":"__semwait_signal","symbolLocation":10,"imageIndex":29},{"imageOffset":62853,"symbol":"nanosleep","symbolLocation":196,"imageIndex":34},{"imageOffset":62858,"sourceLine":37,"sourceFile":"thread.c","symbol":"clic_thread_func","imageIndex":19,"symbolLocation":74},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]}], + + "usedImages" : [ + { + "source" : "P", + "arch" : "x86_64", + "base" : 4486672384, + "CFBundleShortVersionString" : "R 4.4.0 GUI 1.80 Big Sur Intel build", + "CFBundleIdentifier" : "org.R-project.R", + "size" : 589824, + "uuid" : "8311af3a-aa38-355b-acef-bbecbdb69a11", + "path" : "\/Applications\/R.app\/Contents\/MacOS\/R", + "name" : "R", + "CFBundleVersion" : "8376" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4493672448, + "size" : 4472832, + "uuid" : "55f59695-e07b-358e-9273-5927a1204110", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libR.dylib", + + "name" : "libR.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4488380416, + "size" : 180224, + "uuid" : "4b8cfff6-611d-3cfa-ac4a-9f5de50f9039", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRblas.0.dylib", + + "name" : "libRblas.0.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4500307968, + "size" : 2883584, + "uuid" : "1199fc6b-be2f-3ae9-abd5-eca4d24bc45d", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgfortran.5.dylib", + + "name" : "libgfortran.5.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4489015296, + "size" : 278528, + "uuid" : "fa785330-1a6a-3c4f-a00a-d048a122de07", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libquadmath.0.dylib", + + "name" : "libquadmath.0.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4488626176, + "size" : 98304, + "uuid" : "da9b09fe-e0a8-3193-a338-1eb9a68c9fe2", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgcc_s.1.1.dylib", + + "name" : "libgcc_s.1.1.dylib" + }, + { + "source" : "P", + "arch" : "x86_64h", + "base" : 4562251776, + "size" : 65536, + "uuid" : "2dd94238-d463-3bba-bb4e-e65afabe8a76", + "path" : "\/usr\/lib\/libobjc-trampolines.dylib", + "name" : "libobjc-trampolines.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4912177152, + "CFBundleShortVersionString" : "1.0", + "CFBundleIdentifier" : "com.apple.CloudDocsFileProvider", + "size" : 32768, + "uuid" : "ff555cb2-b4f8-36d7-a136-7079179a10ef", + "path" : +"\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/CloudDocsFileProvider.bundle\/Contents\/MacOS\/CloudDocsFileProvider", + + "name" : "CloudDocsFileProvider", + "CFBundleVersion" : "1553.141.1" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4914155520, + "CFBundleShortVersionString" : "855.140.6", + "CFBundleIdentifier" : "com.apple.FileProviderOverride", + "size" : 32768, + "uuid" : "dfea2018-d344-371c-979c-bceb40d6fa63", + "path" : +"\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FileProviderOverride.bundle\/Contents\/MacOS\/FileProviderOverride", + + "name" : "FileProviderOverride", + "CFBundleVersion" : "855.140.6" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4914806784, + "CFBundleShortVersionString" : "13.5", + "CFBundleIdentifier" : +"com.apple.findersync.fileprovideroverride.FinderSyncCollaborationFileProviderOverride", + + "size" : 114688, + "uuid" : "107aab23-364b-394c-898f-6dfaf73eeb08", + "path" : +"\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FinderSyncCollaborationFileProviderOverride.bundle\/Contents\/MacOS\/FinderSyncCollaborationFileProviderOverride", + + "name" : "FinderSyncCollaborationFileProviderOverride", + "CFBundleVersion" : "1564.7.1" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4914253824, + "size" : 32768, + "uuid" : "cd96a11e-e924-3dbd-9eca-5cc0b5d89666", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/methods\/libs\/methods.so", + + "name" : "methods.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4914368512, + "size" : 49152, + "uuid" : "ecf3e70f-c467-39d8-8d83-4e19c3d90174", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/utils\/libs\/utils.so", + + "name" : "utils.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4915519488, + "size" : 294912, + "uuid" : "723f76eb-2518-34f6-934a-d13148a95269", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/grDevices\/libs\/grDevices.so", + + "name" : "grDevices.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4915978240, + "size" : 245760, + "uuid" : "d488156d-368c-3cfe-b68e-746b37d86770", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/graphics\/libs\/graphics.so", + + "name" : "graphics.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 5051109376, + "size" : 688128, + "uuid" : "78bd5e83-92d1-3321-b1c9-df2362e276b8", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/stats\/libs\/stats.so", + + "name" : "stats.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 5054373888, + "size" : 2260992, + "uuid" : "7f659e29-373e-36ea-911e-bb2f3b02eb24", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRlapack.dylib", + + "name" : "libRlapack.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4935864320, + "size" : 81920, + "uuid" : "40112271-4e9e-3bf6-95f0-680dea37d5aa", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/tools\/libs\/tools.so", + + "name" : "tools.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4936028160, + "size" : 49152, + "uuid" : "0a04f808-bb87-3aaf-be91-1414ab3256d2", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/modules\/internet.so", + + "name" : "internet.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4937592832, + "size" : 212992, + "uuid" : "ccb528d9-b2a7-33b3-a0cf-0856d6da4be2", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/rlang\/libs\/rlang.so", + + "name" : "rlang.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4937953280, + "size" : 163840, + "uuid" : "cfdf0b86-8913-3384-800d-78f73c34e6b0", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/cli\/libs\/cli.so", + + "name" : "cli.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4938833920, + "size" : 425984, + "uuid" : "f9f27e74-4e8e-33c0-910b-8e4e80298e65", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/vctrs\/libs\/vctrs.so", + + "name" : "vctrs.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4937293824, + "size" : 16384, + "uuid" : "d8a9a2f8-098d-327b-a9e3-3d3dad680ddb", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/glue\/libs\/glue.so", + + "name" : "glue.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4937265152, + "size" : 12288, + "uuid" : "b6e9c258-16f0-31e8-af63-50207542c35f", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/magrittr\/libs\/magrittr.so", + + "name" : "magrittr.so" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 5029900288, + "size" : 3260416, + "uuid" : "c3e6d895-7059-3865-aa61-a941ea1c4569", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libR.dylib", + + "name" : "libR.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4938199040, + "size" : 180224, + "uuid" : "9f1750d9-e1bf-3a0a-95d8-8c28952d0cf9", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libRblas.0.dylib", + + "name" : "libRblas.0.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4948615168, + "size" : 2301952, + "uuid" : "5b0f7278-9d16-3b60-a413-59eef538e568", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgfortran.5.dylib", + + "name" : "libgfortran.5.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4940275712, + "size" : 233472, + "uuid" : "856f3e97-eecb-3dde-af45-56aea7758a1e", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libquadmath.0.dylib", + + "name" : "libquadmath.0.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 4938428416, + "size" : 90112, + "uuid" : "c1f47ca1-564e-36b8-be6f-7a5fdd88e2c6", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgcc_s.1.dylib", + + "name" : "libgcc_s.1.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703480680448, + "size" : 624112, + "uuid" : "31e1c182-e611-3883-97a3-4334a21c90bd", + "path" : "\/usr\/lib\/dyld", + "name" : "dyld" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703483957248, + "size" : 237568, + "uuid" : "642737ce-21cf-3d87-a7b6-7eea2c080a7e", + "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib", + "name" : "libsystem_kernel.dylib" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703499976704, + "CFBundleShortVersionString" : "6.9", + "CFBundleIdentifier" : "com.apple.Foundation", + "size" : 9998329, + "uuid" : "0cd9336a-bc14-3bc9-9fb9-58e87ca621ba", + "path" : +"\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation", + + "name" : "Foundation", + "CFBundleVersion" : "1979" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703484194816, + "size" : 49152, + "uuid" : "3a3fa85c-f1fe-336c-bf68-924fc947ade3", + "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib", + "name" : "libsystem_pthread.dylib" + }, + { + "source" : "P", + "arch" : "x86_64h", + "base" : 140703484608512, + "CFBundleShortVersionString" : "6.9", + "CFBundleIdentifier" : "com.apple.CoreFoundation", + "size" : 4837360, + "uuid" : "46f56317-e54f-30ca-83e3-516c8156327d", + "path" : +"\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation", + + "name" : "CoreFoundation", + "CFBundleVersion" : "1979" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703535828992, + "CFBundleShortVersionString" : "6.9", + "CFBundleIdentifier" : "com.apple.AppKit", + "size" : 16809984, + "uuid" : "ae00e899-7993-3ab7-a959-d803e7c88dcf", + "path" : +"\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit", + "name" : "AppKit", + "CFBundleVersion" : "2299.70.136" + }, + { + "source" : "P", + "arch" : "x86_64", + "base" : 140703482806272, + "size" : 557048, + "uuid" : "d5b303ad-54f4-323b-bbe2-2d0f34c45649", + "path" : "\/usr\/lib\/system\/libsystem_c.dylib", + "name" : "libsystem_c.dylib" + }, + { + "size" : 0, + "source" : "A", + "base" : 0, + "uuid" : "00000000-0000-0000-0000-000000000000" + } +], + "sharedCache" : { + "base" : 140703480057856, + "size" : 21474836480, + "uuid" : "9e62ff5d-f36e-3c12-9277-95f6a085513e" +}, + "vmSummary" : "ReadOnly portion of Libraries: Total=793.2M +resident=0K(0%) swapped_out_or_unallocated=793.2M(100%)\nWritable regions: +Total=6.0G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) +unallocated=6.0G(100%)\n\n VIRTUAL REGION +\nREGION TYPE SIZE COUNT (non-coalesced) +\n=========== ======= ======= \nAccelerate +framework 256K 2 \nActivity Tracing +256K 1 \nCG backing stores 3072K 4 \nCG +image 1800K 46 \nCG raster +data 8K 1 \nColorSync 272K 32 +\nCoreAnimation 184.4M 130 +\nCoreGraphics 12K 2 \nCoreImage + 432K 18 \nCoreUI image data 4588K +36 \nFoundation 56K 2 \nImage IO + 484K 16 \nJS JIT generated code +1.0G 3 \nKernel Alloc Once 8K 1 +\nMALLOC 266.8M 97 \nMALLOC guard page + 32K 8 \nMALLOC_NANO (reserved) 384.0M + 1 reserved VM address space (unallocated)\nSTACK GUARD + 56.0M 6 \nStack 10.5M 6 +\nVM_ALLOCATE 131.3M 13 \nVM_ALLOCATE +(reserved) 3.9G 1 reserved VM address space +(unallocated)\nWebKit Malloc 192.0M 5 +\n__CTF 824 1 \n__DATA + 35.2M 594 \n__DATA_CONST 37.3M 379 +\n__DATA_DIRTY 1712K 209 +\n__FONT_DATA 2352 1 \n__INFO_FILTER + 8 1 \n__LINKEDIT 175.4M +30 \n__OBJC_RO 66.3M 1 \n__OBJC_RW + 2013K 1 \n__TEXT 617.8M 611 \ndyld +private memory 260K 2 \nmapped +file 239.4M 72 \nshared memory +824K 26 \n=========== ======= ======= +\nTOTAL 7.2G 2359 \nTOTAL, minus reserved +VM space 3.0G 2359 \n", + "legacyInfo" : { + "threadTriggered" : { + "queue" : "com.apple.main-thread" + } +}, + "logWritingSignature" : "6cdfbb491c38e1280753887de64693565d8a493d", + "trialInfo" : { + "rollouts" : [ + { + "rolloutId" : "5ffde50ce2aacd000d47a95f", + "factorPackIds" : { + + }, + "deploymentId" : 240000372 + }, + { + "rolloutId" : "61675b89201f677a9a4cbd65", + "factorPackIds" : { + "HEALTH_FEATURE_AVAILABILITY" : "65a855f5f087695cfac03d1f" + }, + "deploymentId" : 240000112 + } + ], + "experiments" : [ + + ] +} +} + +-- +Carl Witthoft + + [[alternative HTML version deleted]] + + +From pd@|gd @end|ng |rom gm@||@com Tue Apr 30 10:48:07 2024 +From: pd@|gd @end|ng |rom gm@||@com (peter dalgaard) +Date: Tue, 30 Apr 2024 10:48:07 +0200 +Subject: [R-SIG-Mac] R 4.4 crashes loading dplyr +In-Reply-To: +References: +Message-ID: <02808911-83F7-4106-8FEA-E74C6CE0DCB2@gmail.com> + +Hmm, worx4me. At least from a fresh source build. + +I am suspicious of the "4.2" in a number of entries in your log, e.g. + + { + "source" : "P", + "arch" : "x86_64", + "base" : 5029900288, + "size" : 3260416, + "uuid" : "c3e6d895-7059-3865-aa61-a941ea1c4569", + "path" : +"\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libR.dylib", + + "name" : "libR.dylib" + }, + +which suggests that you may be mixing incompatible binaries. Do you have an older private library on your search path? That has bitten me at some point. + + +- pd. + +> On 30 Apr 2024, at 00:55 , Carl Witthoft wrote: +> +> I apologize if the file posted below is the wrong log. +> I start up R 4.4.0 on my iMac 13.5.2 , type 'library(dplyr)' and r.app +> gui crashes immediately. Same for ggplot2, gert, stringr, and others . +> +> I have verified that I've updated every R library in my system. I can +> successfully load other libs, e.g., Rmpfr,knitr, MASS, so I doubt it's a +> directory or permissions problem. +> +> From the command line: +> library(dplyr) +> +> *** caught segfault *** +> address 0x406e0, cause 'memory not mapped' +> +> Traceback: +> 1: fun(libname, pkgname) +> 2: doTryCatch(return(expr), name, parentenv, handler) +> 3: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +> 4: tryCatchList(expr, classes, parentenv, handlers) +> 5: tryCatch(fun(libname, pkgname), error = identity) +> 6: runHook(".onLoad", env, package.lib, package) +> 7: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = +> vI[[j]]) +> 8: asNamespace(ns) +> 9: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc, +> .libPaths()), versionCheck = vI[[j]]), i[[2L]], from = package) +> 10: loadNamespace(package, lib.loc) +> 11: doTryCatch(return(expr), name, parentenv, handler) +> 12: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +> 13: tryCatchList(expr, classes, parentenv, handlers) +> 14: tryCatch({ attr(package, "LibPath") <- which.lib.loc ns <- +> loadNamespace(package, lib.loc) env <- attachNamespace(ns, pos = pos, +> deps, exclude, include.only)}, error = function(e) { P <- if +> (!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L]) +> else "" msg <- gettextf("package or namespace load failed for %s%s:\n +> %s", sQuote(package), P, conditionMessage(e)) if (logical.return +> && !quietly) message(paste("Error:", msg), domain = NA) else +> stop(msg, call. = FALSE, domain = NA)}) +> 15: library(dplyr) +> +> +> +> ---- ~/library/logs/diagnosticreports file pasted below -- +> +> {"app_name":"R","timestamp":"2024-04-29 11:11:39.00 -0400","app_version":"R +> 4.4.0 GUI 1.80 Big Sur Intel +> build","slice_uuid":"8311af3a-aa38-355b-acef-bbecbdb69a11","build_version":"8376","platform":1,"bundleID":"org.R-project.R","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS +> 13.5.2 +> (22G91)","roots_installed":0,"name":"R","incident_id":"059EF229-5343-4EE7-9843-B88A513B8019"} +> +> { +> "uptime" : 260000, +> "procRole" : "Foreground", +> "version" : 2, +> "userID" : 502, +> "deployVersion" : 210, +> "modelCode" : "iMac19,2", +> "coalitionID" : 1308, +> "osVersion" : { +> "train" : "macOS 13.5.2", +> "build" : "22G91", +> "releaseType" : "User" +> }, +> "captureTime" : "2024-04-29 11:11:38.8062 -0400", +> "incident" : "059EF229-5343-4EE7-9843-B88A513B8019", +> "pid" : 55298, +> "cpuType" : "X86-64", +> "roots_installed" : 0, +> "bug_type" : "309", +> "procLaunch" : "2024-04-29 11:10:04.6528 -0400", +> "procStartAbsTime" : 261494660416425, +> "procExitAbsTime" : 261588804970703, +> "procName" : "R", +> "procPath" : "\/Applications\/R.app\/Contents\/MacOS\/R", +> "bundleInfo" : {"CFBundleShortVersionString":"R 4.4.0 GUI 1.80 Big Sur +> Intel +> build","CFBundleVersion":"8376","CFBundleIdentifier":"org.R-project.R"}, +> "storeInfo" : +> {"deviceIdentifierForVendor":"415552B1-5065-5FAB-8DB9-7D60A9149E9E","thirdParty":true}, +> +> "parentProc" : "launchd", +> "parentPid" : 1, +> "coalitionName" : "org.R-project.R", +> "crashReporterKey" : "CD7A5AA1-F53E-DB32-2D97-4F4C0CC4EC41", +> "codeSigningID" : "org.R-project.R", +> "codeSigningTeamID" : "VZLD955F6P", +> "codeSigningFlags" : 570491653, +> "codeSigningValidationCategory" : 6, +> "codeSigningTrustLevel" : 0, +> "wakeTime" : 1661, +> "sleepWakeUUID" : "3454232B-C5AA-4B88-A913-8D5DB632B8A8", +> "sip" : "enabled", +> "vmRegionInfo" : "0x406e0 is not in any region. Bytes before following +> region: 4486408480\n REGION TYPE START - +> END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE AT +> START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +> SM=COW ...tents\/MacOS\/R", +> "exception" : {"codes":"0x0000000000000001, +> 0x00000000000406e0","rawCodes":[1,263904],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS +> at 0x00000000000406e0"}, +> "termination" : +> {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: +> 11","byProc":"exc handler","byPid":55298}, +> "vmregioninfo" : "0x406e0 is not in any region. Bytes before following +> region: 4486408480\n REGION TYPE START - +> END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE AT +> START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +> SM=COW ...tents\/MacOS\/R", +> "extMods" : +> {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0}, +> +> "faultingThread" : 0, +> "threads" : +> [{"triggered":true,"id":2202695,"instructionState":{"instructionStream":{"bytes":[22,0,232,224,92,255,255,72,141,61,137,99,23,0,232,228,217,14,0,15,31,64,0,85,72,137,229,65,87,65,86,65,85,65,84,83,80,73,137,254,232,154,237,247,255,76,99,248,73,105,199,129,28,83,85,72,137,193,72,193,233,63,72,193,248,46,1,200,105,192,5,192,0,0,68,137,249,41,193,72,141,5,161,179,52,0,72,139,0,72,99,201,72,137,77,208,76,139,36,200,72,141,5,196,178,52,0,76,139,40,77,57,236,116,56,15,31,64,0,102,65,131,124,36,6,0,15,133,177,0,0,0,73,139,92,36,32,72,139,115,32,72,131,198,48,76,137,247,232,242,91,22,0,133,192,15,132,130,0,0,0,77,139,100,36,40,77,57,236,117,204,65,128,62,0,15,132,142,0,0,0,76,137,247,232,248,91,22,0,72,61,17],"offset":96}},"threadState":{"r13":{"value":18446744073709551608},"rax":{"value":0},"rflags":{"value":66050},"cpu":{"value":3},"r14":{"value":4937277186},"rsi":{"value":208},"r8":{"value":0},"cr2":{"value":263904},"rdx":{"value":3489660928},"r10":{"value":140468889627856},"r9":{"value": +> 0},"r15":{"value":38277134},"rbx":{"value":1},"trap":{"value":14,"description":"(no +> mapping for user data +> read)"},"err":{"value":4},"r11":{"value":4499443912,"symbolLocation":0,"symbol":"R_BCProtTop"},"rip":{"value":5031094489,"matchesCrashFrame":1},"rbp":{"value":140701862106416},"rsp":{"value":140701862106368},"r12":{"sourceLine":418,"value":4937274544,"sourceFile":"pipe.c","symbol":"magrittr_init","symbolLocation":0},"rcx":{"value":32988},"flavor":"x86_THREAD_STATE","rdi":{"value":4937277200}},"queue":"com.apple.main-thread","frames":[{"imageOffset":1194201,"sourceFile":"names.c","symbol":"Rf_install","symbolLocation":73,"imageIndex":23},{"imageOffset":10802,"sourceLine":117,"sourceFile":"utils.c","symbol":"magrittr_init_utils","imageIndex":22,"symbolLocation":18},{"imageOffset":9411,"sourceLine":420,"sourceFile":"pipe.c","symbol":"magrittr_init","imageIndex":22,"symbolLocation":19},{"imageOffset":601270,"sourceLine":754,"sourceFile":"dotcode.c","symbol":"R_doDotCall","imageIndex":1,"symbolLocation":5686},{"imageOffset":1033939,"sourceLine":8691,"sourceFile":"eval.c","symbol":"bcEval_ +> loop","imageIndex":1,"symbolLocation":146643},{"imageOffset":828276,"sourceLine":7524,"sourceFile":"eval.c","symbol":"bcEval","imageIndex":1,"symbolLocation":628},{"imageOffset":825978,"sourceLine":1167,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":506},{"imageOffset":837049,"sourceLine":2398,"sourceFile":"eval.c","symbol":"R_execClosure","imageIndex":1,"symbolLocation":761},{"imageOffset":833216,"sourceLine":2311,"sourceFile":"eval.c","symbol":"applyClosure_core","imageIndex":1,"symbolLocation":128},{"symbol":"Rf_applyClosure","inline":true,"imageIndex":1,"imageOffset":826661,"symbolLocation":24,"sourceLine":2333,"sourceFile":"eval.c"},{"imageOffset":826661,"sourceLine":1285,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":1189},{"imageOffset":1262209,"sourceLine":398,"sourceFile":"main.c","symbol":"R_ReplDLLdo1","imageIndex":1,"symbolLocation":449},{"imageOffset":125943,"symbol":"run_REngineRmainloop","symbolLocation":263,"imageIn +> dex":0},{"imageOffset":79712,"symbol":"-[REngine +> runREPL]","symbolLocation":144,"imageIndex":0},{"imageOffset":12040,"symbol":"main","symbolLocation":792,"imageIndex":0},{"imageOffset":25631,"symbol":"start","symbolLocation":1903,"imageIndex":28}]},{"id":2202741,"frames":[{"imageOffset":41618,"symbol":"__select","symbolLocation":10,"imageIndex":29},{"imageOffset":22914,"symbol":"-[RController +> readThread:]","symbolLocation":642,"imageIndex":0},{"imageOffset":361987,"symbol":"__NSThread__start__","symbolLocation":1009,"imageIndex":30},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2202791,"name":"com.apple.NSEventThread","frames":[{"imageOffset":5570,"symbol":"mach_msg2_trap","symbolLocation":10,"imageIndex":29},{"imageOffset":63293,"symbol":"mach_msg2_internal","symbolLocation":78,"imageIndex":29},{"imageOffset":34292,"symbol":"mach_msg_overwrite","symbolLocation":692,"imageIndex":29},{"imageOffset":6314,"symbol":"mach_msg","symbolLocation":19,"imageIndex":29},{"imageOffset":512111,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":145,"imageIndex":32},{"imageOffset":506608,"symbol":"__CFRunLoopRun","symbolLocation":1365,"imageIndex":32},{"imageOffset":503601,"symbol":"CFRunLoopRunSpecific","symbolLocation":560,"imageIndex":32},{"imageOffset":1 +> 696757,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":33},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2203120,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203475,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203476,"frames":[{"imageOffset":16334,"symbol":"__semwait_signal","symbolLocation":10,"imageIndex":29},{"imageOffset":62853,"symbol":"nanosleep","symbolLocation":196,"imageIndex":34},{"imageOffset":62858,"sourceLine":37,"sourceFile":"thread.c","symbol":"clic_thread_func","imageIndex":19,"symbolLocation":74},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]}], +> +> "usedImages" : [ +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4486672384, +> "CFBundleShortVersionString" : "R 4.4.0 GUI 1.80 Big Sur Intel build", +> "CFBundleIdentifier" : "org.R-project.R", +> "size" : 589824, +> "uuid" : "8311af3a-aa38-355b-acef-bbecbdb69a11", +> "path" : "\/Applications\/R.app\/Contents\/MacOS\/R", +> "name" : "R", +> "CFBundleVersion" : "8376" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4493672448, +> "size" : 4472832, +> "uuid" : "55f59695-e07b-358e-9273-5927a1204110", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libR.dylib", +> +> "name" : "libR.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4488380416, +> "size" : 180224, +> "uuid" : "4b8cfff6-611d-3cfa-ac4a-9f5de50f9039", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRblas.0.dylib", +> +> "name" : "libRblas.0.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4500307968, +> "size" : 2883584, +> "uuid" : "1199fc6b-be2f-3ae9-abd5-eca4d24bc45d", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgfortran.5.dylib", +> +> "name" : "libgfortran.5.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4489015296, +> "size" : 278528, +> "uuid" : "fa785330-1a6a-3c4f-a00a-d048a122de07", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libquadmath.0.dylib", +> +> "name" : "libquadmath.0.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4488626176, +> "size" : 98304, +> "uuid" : "da9b09fe-e0a8-3193-a338-1eb9a68c9fe2", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgcc_s.1.1.dylib", +> +> "name" : "libgcc_s.1.1.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64h", +> "base" : 4562251776, +> "size" : 65536, +> "uuid" : "2dd94238-d463-3bba-bb4e-e65afabe8a76", +> "path" : "\/usr\/lib\/libobjc-trampolines.dylib", +> "name" : "libobjc-trampolines.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4912177152, +> "CFBundleShortVersionString" : "1.0", +> "CFBundleIdentifier" : "com.apple.CloudDocsFileProvider", +> "size" : 32768, +> "uuid" : "ff555cb2-b4f8-36d7-a136-7079179a10ef", +> "path" : +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/CloudDocsFileProvider.bundle\/Contents\/MacOS\/CloudDocsFileProvider", +> +> "name" : "CloudDocsFileProvider", +> "CFBundleVersion" : "1553.141.1" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4914155520, +> "CFBundleShortVersionString" : "855.140.6", +> "CFBundleIdentifier" : "com.apple.FileProviderOverride", +> "size" : 32768, +> "uuid" : "dfea2018-d344-371c-979c-bceb40d6fa63", +> "path" : +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FileProviderOverride.bundle\/Contents\/MacOS\/FileProviderOverride", +> +> "name" : "FileProviderOverride", +> "CFBundleVersion" : "855.140.6" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4914806784, +> "CFBundleShortVersionString" : "13.5", +> "CFBundleIdentifier" : +> "com.apple.findersync.fileprovideroverride.FinderSyncCollaborationFileProviderOverride", +> +> "size" : 114688, +> "uuid" : "107aab23-364b-394c-898f-6dfaf73eeb08", +> "path" : +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FinderSyncCollaborationFileProviderOverride.bundle\/Contents\/MacOS\/FinderSyncCollaborationFileProviderOverride", +> +> "name" : "FinderSyncCollaborationFileProviderOverride", +> "CFBundleVersion" : "1564.7.1" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4914253824, +> "size" : 32768, +> "uuid" : "cd96a11e-e924-3dbd-9eca-5cc0b5d89666", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/methods\/libs\/methods.so", +> +> "name" : "methods.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4914368512, +> "size" : 49152, +> "uuid" : "ecf3e70f-c467-39d8-8d83-4e19c3d90174", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/utils\/libs\/utils.so", +> +> "name" : "utils.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4915519488, +> "size" : 294912, +> "uuid" : "723f76eb-2518-34f6-934a-d13148a95269", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/grDevices\/libs\/grDevices.so", +> +> "name" : "grDevices.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4915978240, +> "size" : 245760, +> "uuid" : "d488156d-368c-3cfe-b68e-746b37d86770", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/graphics\/libs\/graphics.so", +> +> "name" : "graphics.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 5051109376, +> "size" : 688128, +> "uuid" : "78bd5e83-92d1-3321-b1c9-df2362e276b8", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/stats\/libs\/stats.so", +> +> "name" : "stats.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 5054373888, +> "size" : 2260992, +> "uuid" : "7f659e29-373e-36ea-911e-bb2f3b02eb24", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRlapack.dylib", +> +> "name" : "libRlapack.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4935864320, +> "size" : 81920, +> "uuid" : "40112271-4e9e-3bf6-95f0-680dea37d5aa", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/tools\/libs\/tools.so", +> +> "name" : "tools.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4936028160, +> "size" : 49152, +> "uuid" : "0a04f808-bb87-3aaf-be91-1414ab3256d2", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/modules\/internet.so", +> +> "name" : "internet.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4937592832, +> "size" : 212992, +> "uuid" : "ccb528d9-b2a7-33b3-a0cf-0856d6da4be2", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/rlang\/libs\/rlang.so", +> +> "name" : "rlang.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4937953280, +> "size" : 163840, +> "uuid" : "cfdf0b86-8913-3384-800d-78f73c34e6b0", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/cli\/libs\/cli.so", +> +> "name" : "cli.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4938833920, +> "size" : 425984, +> "uuid" : "f9f27e74-4e8e-33c0-910b-8e4e80298e65", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/vctrs\/libs\/vctrs.so", +> +> "name" : "vctrs.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4937293824, +> "size" : 16384, +> "uuid" : "d8a9a2f8-098d-327b-a9e3-3d3dad680ddb", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/glue\/libs\/glue.so", +> +> "name" : "glue.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4937265152, +> "size" : 12288, +> "uuid" : "b6e9c258-16f0-31e8-af63-50207542c35f", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/magrittr\/libs\/magrittr.so", +> +> "name" : "magrittr.so" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 5029900288, +> "size" : 3260416, +> "uuid" : "c3e6d895-7059-3865-aa61-a941ea1c4569", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libR.dylib", +> +> "name" : "libR.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4938199040, +> "size" : 180224, +> "uuid" : "9f1750d9-e1bf-3a0a-95d8-8c28952d0cf9", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libRblas.0.dylib", +> +> "name" : "libRblas.0.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4948615168, +> "size" : 2301952, +> "uuid" : "5b0f7278-9d16-3b60-a413-59eef538e568", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgfortran.5.dylib", +> +> "name" : "libgfortran.5.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4940275712, +> "size" : 233472, +> "uuid" : "856f3e97-eecb-3dde-af45-56aea7758a1e", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libquadmath.0.dylib", +> +> "name" : "libquadmath.0.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 4938428416, +> "size" : 90112, +> "uuid" : "c1f47ca1-564e-36b8-be6f-7a5fdd88e2c6", +> "path" : +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgcc_s.1.dylib", +> +> "name" : "libgcc_s.1.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703480680448, +> "size" : 624112, +> "uuid" : "31e1c182-e611-3883-97a3-4334a21c90bd", +> "path" : "\/usr\/lib\/dyld", +> "name" : "dyld" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703483957248, +> "size" : 237568, +> "uuid" : "642737ce-21cf-3d87-a7b6-7eea2c080a7e", +> "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib", +> "name" : "libsystem_kernel.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703499976704, +> "CFBundleShortVersionString" : "6.9", +> "CFBundleIdentifier" : "com.apple.Foundation", +> "size" : 9998329, +> "uuid" : "0cd9336a-bc14-3bc9-9fb9-58e87ca621ba", +> "path" : +> "\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation", +> +> "name" : "Foundation", +> "CFBundleVersion" : "1979" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703484194816, +> "size" : 49152, +> "uuid" : "3a3fa85c-f1fe-336c-bf68-924fc947ade3", +> "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib", +> "name" : "libsystem_pthread.dylib" +> }, +> { +> "source" : "P", +> "arch" : "x86_64h", +> "base" : 140703484608512, +> "CFBundleShortVersionString" : "6.9", +> "CFBundleIdentifier" : "com.apple.CoreFoundation", +> "size" : 4837360, +> "uuid" : "46f56317-e54f-30ca-83e3-516c8156327d", +> "path" : +> "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation", +> +> "name" : "CoreFoundation", +> "CFBundleVersion" : "1979" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703535828992, +> "CFBundleShortVersionString" : "6.9", +> "CFBundleIdentifier" : "com.apple.AppKit", +> "size" : 16809984, +> "uuid" : "ae00e899-7993-3ab7-a959-d803e7c88dcf", +> "path" : +> "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit", +> "name" : "AppKit", +> "CFBundleVersion" : "2299.70.136" +> }, +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 140703482806272, +> "size" : 557048, +> "uuid" : "d5b303ad-54f4-323b-bbe2-2d0f34c45649", +> "path" : "\/usr\/lib\/system\/libsystem_c.dylib", +> "name" : "libsystem_c.dylib" +> }, +> { +> "size" : 0, +> "source" : "A", +> "base" : 0, +> "uuid" : "00000000-0000-0000-0000-000000000000" +> } +> ], +> "sharedCache" : { +> "base" : 140703480057856, +> "size" : 21474836480, +> "uuid" : "9e62ff5d-f36e-3c12-9277-95f6a085513e" +> }, +> "vmSummary" : "ReadOnly portion of Libraries: Total=793.2M +> resident=0K(0%) swapped_out_or_unallocated=793.2M(100%)\nWritable regions: +> Total=6.0G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) +> unallocated=6.0G(100%)\n\n VIRTUAL REGION +> \nREGION TYPE SIZE COUNT (non-coalesced) +> \n=========== ======= ======= \nAccelerate +> framework 256K 2 \nActivity Tracing +> 256K 1 \nCG backing stores 3072K 4 \nCG +> image 1800K 46 \nCG raster +> data 8K 1 \nColorSync 272K 32 +> \nCoreAnimation 184.4M 130 +> \nCoreGraphics 12K 2 \nCoreImage +> 432K 18 \nCoreUI image data 4588K +> 36 \nFoundation 56K 2 \nImage IO +> 484K 16 \nJS JIT generated code +> 1.0G 3 \nKernel Alloc Once 8K 1 +> \nMALLOC 266.8M 97 \nMALLOC guard page +> 32K 8 \nMALLOC_NANO (reserved) 384.0M +> 1 reserved VM address space (unallocated)\nSTACK GUARD +> 56.0M 6 \nStack 10.5M 6 +> \nVM_ALLOCATE 131.3M 13 \nVM_ALLOCATE +> (reserved) 3.9G 1 reserved VM address space +> (unallocated)\nWebKit Malloc 192.0M 5 +> \n__CTF 824 1 \n__DATA +> 35.2M 594 \n__DATA_CONST 37.3M 379 +> \n__DATA_DIRTY 1712K 209 +> \n__FONT_DATA 2352 1 \n__INFO_FILTER +> 8 1 \n__LINKEDIT 175.4M +> 30 \n__OBJC_RO 66.3M 1 \n__OBJC_RW +> 2013K 1 \n__TEXT 617.8M 611 \ndyld +> private memory 260K 2 \nmapped +> file 239.4M 72 \nshared memory +> 824K 26 \n=========== ======= ======= +> \nTOTAL 7.2G 2359 \nTOTAL, minus reserved +> VM space 3.0G 2359 \n", +> "legacyInfo" : { +> "threadTriggered" : { +> "queue" : "com.apple.main-thread" +> } +> }, +> "logWritingSignature" : "6cdfbb491c38e1280753887de64693565d8a493d", +> "trialInfo" : { +> "rollouts" : [ +> { +> "rolloutId" : "5ffde50ce2aacd000d47a95f", +> "factorPackIds" : { +> +> }, +> "deploymentId" : 240000372 +> }, +> { +> "rolloutId" : "61675b89201f677a9a4cbd65", +> "factorPackIds" : { +> "HEALTH_FEATURE_AVAILABILITY" : "65a855f5f087695cfac03d1f" +> }, +> "deploymentId" : 240000112 +> } +> ], +> "experiments" : [ +> +> ] +> } +> } +> +> -- +> Carl Witthoft +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac + +-- +Peter Dalgaard, Professor, +Center for Statistics, Copenhagen Business School +Solbjerg Plads 3, 2000 Frederiksberg, Denmark +Phone: (+45)38153501 +Office: A 4.23 +Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com + + +From ce||ocgw @end|ng |rom gm@||@com Tue Apr 30 14:32:41 2024 +From: ce||ocgw @end|ng |rom gm@||@com (Carl Witthoft) +Date: Tue, 30 Apr 2024 08:32:41 -0400 +Subject: [R-SIG-Mac] R 4.4 crashes loading dplyr +In-Reply-To: <02808911-83F7-4106-8FEA-E74C6CE0DCB2@gmail.com> +References: + <02808911-83F7-4106-8FEA-E74C6CE0DCB2@gmail.com> +Message-ID: + +Thanks, Peter! The funny thing is that I had kept R 4.2 around in the +Frameworks directory, but didn't expect a new installation of R4.4 to +choose that path for libs. I removed R4.2 , then reinstalled R4.4 and now +the correct libs are invoked. I guess some config macro file must have +remained in the list of startup items. +FWIW, after removing R4.2 but before reinstalling R4.4, I tried +'library(dplyr)' , which didn't crash but failed with the error msgs shown +here. +Error: package or namespace load failed for ?dplyr? in dyn.load(file, +DLLpath = DLLpath, ...): + unable to load shared object +'/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so': + +dlopen(/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so, +0x0006): Library not loaded: +/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib + Referenced from: +/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so + Reason: tried: +'/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no +such file), +'/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' +(no such file), +'/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no +such file), '/usr/local/lib/libR.dylib' (no such file), +'/usr/lib/libR.dylib' (no such file, not in dyld cac + +regards, +Carl + +On Tue, Apr 30, 2024 at 4:48?AM peter dalgaard wrote: + +> Hmm, worx4me. At least from a fresh source build. +> +> I am suspicious of the "4.2" in a number of entries in your log, e.g. +> +> { +> "source" : "P", +> "arch" : "x86_64", +> "base" : 5029900288, +> "size" : 3260416, +> "uuid" : "c3e6d895-7059-3865-aa61-a941ea1c4569", +> "path" : +> +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libR.dylib", +> +> "name" : "libR.dylib" +> }, +> +> which suggests that you may be mixing incompatible binaries. Do you have +> an older private library on your search path? That has bitten me at some +> point. +> +> +> - pd. +> +> > On 30 Apr 2024, at 00:55 , Carl Witthoft wrote: +> > +> > I apologize if the file posted below is the wrong log. +> > I start up R 4.4.0 on my iMac 13.5.2 , type 'library(dplyr)' and r.app +> > gui crashes immediately. Same for ggplot2, gert, stringr, and others . +> > +> > I have verified that I've updated every R library in my system. I can +> > successfully load other libs, e.g., Rmpfr,knitr, MASS, so I doubt it's a +> > directory or permissions problem. +> > +> > From the command line: +> > library(dplyr) +> > +> > *** caught segfault *** +> > address 0x406e0, cause 'memory not mapped' +> > +> > Traceback: +> > 1: fun(libname, pkgname) +> > 2: doTryCatch(return(expr), name, parentenv, handler) +> > 3: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +> > 4: tryCatchList(expr, classes, parentenv, handlers) +> > 5: tryCatch(fun(libname, pkgname), error = identity) +> > 6: runHook(".onLoad", env, package.lib, package) +> > 7: loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = +> > vI[[j]]) +> > 8: asNamespace(ns) +> > 9: namespaceImportFrom(ns, loadNamespace(j <- i[[1L]], c(lib.loc, +> > .libPaths()), versionCheck = vI[[j]]), i[[2L]], from = package) +> > 10: loadNamespace(package, lib.loc) +> > 11: doTryCatch(return(expr), name, parentenv, handler) +> > 12: tryCatchOne(expr, names, parentenv, handlers[[1L]]) +> > 13: tryCatchList(expr, classes, parentenv, handlers) +> > 14: tryCatch({ attr(package, "LibPath") <- which.lib.loc ns <- +> > loadNamespace(package, lib.loc) env <- attachNamespace(ns, pos = pos, +> > deps, exclude, include.only)}, error = function(e) { P <- if +> > (!is.null(cc <- conditionCall(e))) paste(" in", deparse(cc)[1L]) +> > else "" msg <- gettextf("package or namespace load failed for %s%s:\n +> > %s", sQuote(package), P, conditionMessage(e)) if +> (logical.return +> > && !quietly) message(paste("Error:", msg), domain = NA) else +> > stop(msg, call. = FALSE, domain = NA)}) +> > 15: library(dplyr) +> > +> > +> > +> > ---- ~/library/logs/diagnosticreports file pasted below -- +> > +> > {"app_name":"R","timestamp":"2024-04-29 11:11:39.00 +> -0400","app_version":"R +> > 4.4.0 GUI 1.80 Big Sur Intel +> > +> build","slice_uuid":"8311af3a-aa38-355b-acef-bbecbdb69a11","build_version":"8376","platform":1,"bundleID":"org.R-project.R","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS +> > 13.5.2 +> > +> (22G91)","roots_installed":0,"name":"R","incident_id":"059EF229-5343-4EE7-9843-B88A513B8019"} +> > +> > { +> > "uptime" : 260000, +> > "procRole" : "Foreground", +> > "version" : 2, +> > "userID" : 502, +> > "deployVersion" : 210, +> > "modelCode" : "iMac19,2", +> > "coalitionID" : 1308, +> > "osVersion" : { +> > "train" : "macOS 13.5.2", +> > "build" : "22G91", +> > "releaseType" : "User" +> > }, +> > "captureTime" : "2024-04-29 11:11:38.8062 -0400", +> > "incident" : "059EF229-5343-4EE7-9843-B88A513B8019", +> > "pid" : 55298, +> > "cpuType" : "X86-64", +> > "roots_installed" : 0, +> > "bug_type" : "309", +> > "procLaunch" : "2024-04-29 11:10:04.6528 -0400", +> > "procStartAbsTime" : 261494660416425, +> > "procExitAbsTime" : 261588804970703, +> > "procName" : "R", +> > "procPath" : "\/Applications\/R.app\/Contents\/MacOS\/R", +> > "bundleInfo" : {"CFBundleShortVersionString":"R 4.4.0 GUI 1.80 Big Sur +> > Intel +> > build","CFBundleVersion":"8376","CFBundleIdentifier":"org.R-project.R"}, +> > "storeInfo" : +> > +> {"deviceIdentifierForVendor":"415552B1-5065-5FAB-8DB9-7D60A9149E9E","thirdParty":true}, +> > +> > "parentProc" : "launchd", +> > "parentPid" : 1, +> > "coalitionName" : "org.R-project.R", +> > "crashReporterKey" : "CD7A5AA1-F53E-DB32-2D97-4F4C0CC4EC41", +> > "codeSigningID" : "org.R-project.R", +> > "codeSigningTeamID" : "VZLD955F6P", +> > "codeSigningFlags" : 570491653, +> > "codeSigningValidationCategory" : 6, +> > "codeSigningTrustLevel" : 0, +> > "wakeTime" : 1661, +> > "sleepWakeUUID" : "3454232B-C5AA-4B88-A913-8D5DB632B8A8", +> > "sip" : "enabled", +> > "vmRegionInfo" : "0x406e0 is not in any region. Bytes before following +> > region: 4486408480\n REGION TYPE START - +> > END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE +> AT +> > START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +> > SM=COW ...tents\/MacOS\/R", +> > "exception" : {"codes":"0x0000000000000001, +> > +> 0x00000000000406e0","rawCodes":[1,263904],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS +> > at 0x00000000000406e0"}, +> > "termination" : +> > {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation +> fault: +> > 11","byProc":"exc handler","byPid":55298}, +> > "vmregioninfo" : "0x406e0 is not in any region. Bytes before following +> > region: 4486408480\n REGION TYPE START - +> > END [ VSIZE] PRT\/MAX SHRMOD REGION DETAIL\n UNUSED SPACE +> AT +> > START\n---> \n __TEXT 10b6d3000-10b763000 [ 576K] r-x\/r-x +> > SM=COW ...tents\/MacOS\/R", +> > "extMods" : +> > +> {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0}, +> > +> > "faultingThread" : 0, +> > "threads" : +> > +> [{"triggered":true,"id":2202695,"instructionState":{"instructionStream":{"bytes":[22,0,232,224,92,255,255,72,141,61,137,99,23,0,232,228,217,14,0,15,31,64,0,85,72,137,229,65,87,65,86,65,85,65,84,83,80,73,137,254,232,154,237,247,255,76,99,248,73,105,199,129,28,83,85,72,137,193,72,193,233,63,72,193,248,46,1,200,105,192,5,192,0,0,68,137,249,41,193,72,141,5,161,179,52,0,72,139,0,72,99,201,72,137,77,208,76,139,36,200,72,141,5,196,178,52,0,76,139,40,77,57,236,116,56,15,31,64,0,102,65,131,124,36,6,0,15,133,177,0,0,0,73,139,92,36,32,72,139,115,32,72,131,198,48,76,137,247,232,242,91,22,0,133,192,15,132,130,0,0,0,77,139,100,36,40,77,57,236,117,204,65,128,62,0,15,132,142,0,0,0,76,137,247,232,248,91,22,0,72,61,17],"offset":96}},"threadState":{"r13":{"value":18446744073709551608},"rax":{"value":0},"rflags":{"value":66050},"cpu":{"value":3},"r14":{"value":4937277186},"rsi":{"value":208},"r8":{"value":0},"cr2":{"value":263904},"rdx":{"value":3489660928},"r10":{"value":140468889627856},"r9":{"value": +> > +> 0},"r15":{"value":38277134},"rbx":{"value":1},"trap":{"value":14,"description":"(no +> > mapping for user data +> > +> read)"},"err":{"value":4},"r11":{"value":4499443912,"symbolLocation":0,"symbol":"R_BCProtTop"},"rip":{"value":5031094489,"matchesCrashFrame":1},"rbp":{"value":140701862106416},"rsp":{"value":140701862106368},"r12":{"sourceLine":418,"value":4937274544,"sourceFile":"pipe.c","symbol":"magrittr_init","symbolLocation":0},"rcx":{"value":32988},"flavor":"x86_THREAD_STATE","rdi":{"value":4937277200}},"queue":"com.apple.main-thread","frames":[{"imageOffset":1194201,"sourceFile":"names.c","symbol":"Rf_install","symbolLocation":73,"imageIndex":23},{"imageOffset":10802,"sourceLine":117,"sourceFile":"utils.c","symbol":"magrittr_init_utils","imageIndex":22,"symbolLocation":18},{"imageOffset":9411,"sourceLine":420,"sourceFile":"pipe.c","symbol":"magrittr_init","imageIndex":22,"symbolLocation":19},{"imageOffset":601270,"sourceLine":754,"sourceFile":"dotcode.c","symbol":"R_doDotCall","imageIndex":1,"symbolLocation":5686},{"imageOffset":1033939,"sourceLine":8691,"sourceFile":"eval.c","symbol":"bcEval_ +> > +> loop","imageIndex":1,"symbolLocation":146643},{"imageOffset":828276,"sourceLine":7524,"sourceFile":"eval.c","symbol":"bcEval","imageIndex":1,"symbolLocation":628},{"imageOffset":825978,"sourceLine":1167,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":506},{"imageOffset":837049,"sourceLine":2398,"sourceFile":"eval.c","symbol":"R_execClosure","imageIndex":1,"symbolLocation":761},{"imageOffset":833216,"sourceLine":2311,"sourceFile":"eval.c","symbol":"applyClosure_core","imageIndex":1,"symbolLocation":128},{"symbol":"Rf_applyClosure","inline":true,"imageIndex":1,"imageOffset":826661,"symbolLocation":24,"sourceLine":2333,"sourceFile":"eval.c"},{"imageOffset":826661,"sourceLine":1285,"sourceFile":"eval.c","symbol":"Rf_eval","imageIndex":1,"symbolLocation":1189},{"imageOffset":1262209,"sourceLine":398,"sourceFile":"main.c","symbol":"R_ReplDLLdo1","imageIndex":1,"symbolLocation":449},{"imageOffset":125943,"symbol":"run_REngineRmainloop","symbolLocation":263,"imageIn +> > dex":0},{"imageOffset":79712,"symbol":"-[REngine +> > +> runREPL]","symbolLocation":144,"imageIndex":0},{"imageOffset":12040,"symbol":"main","symbolLocation":792,"imageIndex":0},{"imageOffset":25631,"symbol":"start","symbolLocation":1903,"imageIndex":28}]},{"id":2202741,"frames":[{"imageOffset":41618,"symbol":"__select","symbolLocation":10,"imageIndex":29},{"imageOffset":22914,"symbol":"-[RController +> > +> readThread:]","symbolLocation":642,"imageIndex":0},{"imageOffset":361987,"symbol":"__NSThread__start__","symbolLocation":1009,"imageIndex":30},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2202791,"name":"com.apple.NSEventThread","frames":[{"imageOffset":5570,"symbol":"mach_msg2_trap","symbolLocation":10,"imageIndex":29},{"imageOffset":63293,"symbol":"mach_msg2_internal","symbolLocation":78,"imageIndex":29},{"imageOffset":34292,"symbol":"mach_msg_overwrite","symbolLocation":692,"imageIndex":29},{"imageOffset":6314,"symbol":"mach_msg","symbolLocation":19,"imageIndex":29},{"imageOffset":512111,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":145,"imageIndex":32},{"imageOffset":506608,"symbol":"__CFRunLoopRun","symbolLocation":1365,"imageIndex":32},{"imageOffset":503601,"symbol":"CFRunLoopRunSpecific","symbolLocation":560,"imageIndex":32},{"imageOffset":1 +> > +> 696757,"symbol":"_NSEventThread","symbolLocation":132,"imageIndex":33},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]},{"id":2203120,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203475,"frames":[{"imageOffset":7088,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":31}]},{"id":2203476,"frames":[{"imageOffset":16334,"symbol":"__semwait_signal","symbolLocation":10,"imageIndex":29},{"imageOffset":62853,"symbol":"nanosleep","symbolLocation":196,"imageIndex":34},{"imageOffset":62858,"sourceLine":37,"sourceFile":"thread.c","symbol":"clic_thread_func","imageIndex":19,"symbolLocation":74},{"imageOffset":25043,"symbol":"_pthread_start","symbolLocation":125,"imageIndex":31},{"imageOffset":7123,"symbol":"thread_start","symbolLocation":15,"imageIndex":31}]}], +> > +> > "usedImages" : [ +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4486672384, +> > "CFBundleShortVersionString" : "R 4.4.0 GUI 1.80 Big Sur Intel build", +> > "CFBundleIdentifier" : "org.R-project.R", +> > "size" : 589824, +> > "uuid" : "8311af3a-aa38-355b-acef-bbecbdb69a11", +> > "path" : "\/Applications\/R.app\/Contents\/MacOS\/R", +> > "name" : "R", +> > "CFBundleVersion" : "8376" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4493672448, +> > "size" : 4472832, +> > "uuid" : "55f59695-e07b-358e-9273-5927a1204110", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libR.dylib", +> > +> > "name" : "libR.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4488380416, +> > "size" : 180224, +> > "uuid" : "4b8cfff6-611d-3cfa-ac4a-9f5de50f9039", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRblas.0.dylib", +> > +> > "name" : "libRblas.0.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4500307968, +> > "size" : 2883584, +> > "uuid" : "1199fc6b-be2f-3ae9-abd5-eca4d24bc45d", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgfortran.5.dylib", +> > +> > "name" : "libgfortran.5.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4489015296, +> > "size" : 278528, +> > "uuid" : "fa785330-1a6a-3c4f-a00a-d048a122de07", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libquadmath.0.dylib", +> > +> > "name" : "libquadmath.0.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4488626176, +> > "size" : 98304, +> > "uuid" : "da9b09fe-e0a8-3193-a338-1eb9a68c9fe2", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libgcc_s.1.1.dylib", +> > +> > "name" : "libgcc_s.1.1.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64h", +> > "base" : 4562251776, +> > "size" : 65536, +> > "uuid" : "2dd94238-d463-3bba-bb4e-e65afabe8a76", +> > "path" : "\/usr\/lib\/libobjc-trampolines.dylib", +> > "name" : "libobjc-trampolines.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4912177152, +> > "CFBundleShortVersionString" : "1.0", +> > "CFBundleIdentifier" : "com.apple.CloudDocsFileProvider", +> > "size" : 32768, +> > "uuid" : "ff555cb2-b4f8-36d7-a136-7079179a10ef", +> > "path" : +> > +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/CloudDocsFileProvider.bundle\/Contents\/MacOS\/CloudDocsFileProvider", +> > +> > "name" : "CloudDocsFileProvider", +> > "CFBundleVersion" : "1553.141.1" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4914155520, +> > "CFBundleShortVersionString" : "855.140.6", +> > "CFBundleIdentifier" : "com.apple.FileProviderOverride", +> > "size" : 32768, +> > "uuid" : "dfea2018-d344-371c-979c-bceb40d6fa63", +> > "path" : +> > +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FileProviderOverride.bundle\/Contents\/MacOS\/FileProviderOverride", +> > +> > "name" : "FileProviderOverride", +> > "CFBundleVersion" : "855.140.6" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4914806784, +> > "CFBundleShortVersionString" : "13.5", +> > "CFBundleIdentifier" : +> > +> "com.apple.findersync.fileprovideroverride.FinderSyncCollaborationFileProviderOverride", +> > +> > "size" : 114688, +> > "uuid" : "107aab23-364b-394c-898f-6dfaf73eeb08", +> > "path" : +> > +> "\/System\/Library\/Frameworks\/FileProvider.framework\/OverrideBundles\/FinderSyncCollaborationFileProviderOverride.bundle\/Contents\/MacOS\/FinderSyncCollaborationFileProviderOverride", +> > +> > "name" : "FinderSyncCollaborationFileProviderOverride", +> > "CFBundleVersion" : "1564.7.1" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4914253824, +> > "size" : 32768, +> > "uuid" : "cd96a11e-e924-3dbd-9eca-5cc0b5d89666", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/methods\/libs\/methods.so", +> > +> > "name" : "methods.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4914368512, +> > "size" : 49152, +> > "uuid" : "ecf3e70f-c467-39d8-8d83-4e19c3d90174", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/utils\/libs\/utils.so", +> > +> > "name" : "utils.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4915519488, +> > "size" : 294912, +> > "uuid" : "723f76eb-2518-34f6-934a-d13148a95269", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/grDevices\/libs\/grDevices.so", +> > +> > "name" : "grDevices.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4915978240, +> > "size" : 245760, +> > "uuid" : "d488156d-368c-3cfe-b68e-746b37d86770", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/graphics\/libs\/graphics.so", +> > +> > "name" : "graphics.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 5051109376, +> > "size" : 688128, +> > "uuid" : "78bd5e83-92d1-3321-b1c9-df2362e276b8", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/stats\/libs\/stats.so", +> > +> > "name" : "stats.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 5054373888, +> > "size" : 2260992, +> > "uuid" : "7f659e29-373e-36ea-911e-bb2f3b02eb24", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/lib\/libRlapack.dylib", +> > +> > "name" : "libRlapack.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4935864320, +> > "size" : 81920, +> > "uuid" : "40112271-4e9e-3bf6-95f0-680dea37d5aa", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/tools\/libs\/tools.so", +> > +> > "name" : "tools.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4936028160, +> > "size" : 49152, +> > "uuid" : "0a04f808-bb87-3aaf-be91-1414ab3256d2", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/modules\/internet.so", +> > +> > "name" : "internet.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4937592832, +> > "size" : 212992, +> > "uuid" : "ccb528d9-b2a7-33b3-a0cf-0856d6da4be2", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/rlang\/libs\/rlang.so", +> > +> > "name" : "rlang.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4937953280, +> > "size" : 163840, +> > "uuid" : "cfdf0b86-8913-3384-800d-78f73c34e6b0", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/cli\/libs\/cli.so", +> > +> > "name" : "cli.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4938833920, +> > "size" : 425984, +> > "uuid" : "f9f27e74-4e8e-33c0-910b-8e4e80298e65", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/vctrs\/libs\/vctrs.so", +> > +> > "name" : "vctrs.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4937293824, +> > "size" : 16384, +> > "uuid" : "d8a9a2f8-098d-327b-a9e3-3d3dad680ddb", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/glue\/libs\/glue.so", +> > +> > "name" : "glue.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4937265152, +> > "size" : 12288, +> > "uuid" : "b6e9c258-16f0-31e8-af63-50207542c35f", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.4-x86_64\/Resources\/library\/magrittr\/libs\/magrittr.so", +> > +> > "name" : "magrittr.so" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 5029900288, +> > "size" : 3260416, +> > "uuid" : "c3e6d895-7059-3865-aa61-a941ea1c4569", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libR.dylib", +> > +> > "name" : "libR.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4938199040, +> > "size" : 180224, +> > "uuid" : "9f1750d9-e1bf-3a0a-95d8-8c28952d0cf9", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libRblas.0.dylib", +> > +> > "name" : "libRblas.0.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4948615168, +> > "size" : 2301952, +> > "uuid" : "5b0f7278-9d16-3b60-a413-59eef538e568", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgfortran.5.dylib", +> > +> > "name" : "libgfortran.5.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4940275712, +> > "size" : 233472, +> > "uuid" : "856f3e97-eecb-3dde-af45-56aea7758a1e", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libquadmath.0.dylib", +> > +> > "name" : "libquadmath.0.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 4938428416, +> > "size" : 90112, +> > "uuid" : "c1f47ca1-564e-36b8-be6f-7a5fdd88e2c6", +> > "path" : +> > +> "\/Library\/Frameworks\/R.framework\/Versions\/4.2\/Resources\/lib\/libgcc_s.1.dylib", +> > +> > "name" : "libgcc_s.1.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703480680448, +> > "size" : 624112, +> > "uuid" : "31e1c182-e611-3883-97a3-4334a21c90bd", +> > "path" : "\/usr\/lib\/dyld", +> > "name" : "dyld" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703483957248, +> > "size" : 237568, +> > "uuid" : "642737ce-21cf-3d87-a7b6-7eea2c080a7e", +> > "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib", +> > "name" : "libsystem_kernel.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703499976704, +> > "CFBundleShortVersionString" : "6.9", +> > "CFBundleIdentifier" : "com.apple.Foundation", +> > "size" : 9998329, +> > "uuid" : "0cd9336a-bc14-3bc9-9fb9-58e87ca621ba", +> > "path" : +> > +> "\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation", +> > +> > "name" : "Foundation", +> > "CFBundleVersion" : "1979" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703484194816, +> > "size" : 49152, +> > "uuid" : "3a3fa85c-f1fe-336c-bf68-924fc947ade3", +> > "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib", +> > "name" : "libsystem_pthread.dylib" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64h", +> > "base" : 140703484608512, +> > "CFBundleShortVersionString" : "6.9", +> > "CFBundleIdentifier" : "com.apple.CoreFoundation", +> > "size" : 4837360, +> > "uuid" : "46f56317-e54f-30ca-83e3-516c8156327d", +> > "path" : +> > +> "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation", +> > +> > "name" : "CoreFoundation", +> > "CFBundleVersion" : "1979" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703535828992, +> > "CFBundleShortVersionString" : "6.9", +> > "CFBundleIdentifier" : "com.apple.AppKit", +> > "size" : 16809984, +> > "uuid" : "ae00e899-7993-3ab7-a959-d803e7c88dcf", +> > "path" : +> > "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit", +> > "name" : "AppKit", +> > "CFBundleVersion" : "2299.70.136" +> > }, +> > { +> > "source" : "P", +> > "arch" : "x86_64", +> > "base" : 140703482806272, +> > "size" : 557048, +> > "uuid" : "d5b303ad-54f4-323b-bbe2-2d0f34c45649", +> > "path" : "\/usr\/lib\/system\/libsystem_c.dylib", +> > "name" : "libsystem_c.dylib" +> > }, +> > { +> > "size" : 0, +> > "source" : "A", +> > "base" : 0, +> > "uuid" : "00000000-0000-0000-0000-000000000000" +> > } +> > ], +> > "sharedCache" : { +> > "base" : 140703480057856, +> > "size" : 21474836480, +> > "uuid" : "9e62ff5d-f36e-3c12-9277-95f6a085513e" +> > }, +> > "vmSummary" : "ReadOnly portion of Libraries: Total=793.2M +> > resident=0K(0%) swapped_out_or_unallocated=793.2M(100%)\nWritable +> regions: +> > Total=6.0G written=0K(0%) resident=0K(0%) swapped_out=0K(0%) +> > unallocated=6.0G(100%)\n\n VIRTUAL REGION +> > \nREGION TYPE SIZE COUNT (non-coalesced) +> > \n=========== ======= ======= \nAccelerate +> > framework 256K 2 \nActivity Tracing +> > 256K 1 \nCG backing stores 3072K 4 \nCG +> > image 1800K 46 \nCG raster +> > data 8K 1 \nColorSync 272K 32 +> > \nCoreAnimation 184.4M 130 +> > \nCoreGraphics 12K 2 \nCoreImage +> > 432K 18 \nCoreUI image data 4588K +> > 36 \nFoundation 56K 2 \nImage IO +> > 484K 16 \nJS JIT generated code +> > 1.0G 3 \nKernel Alloc Once 8K 1 +> > \nMALLOC 266.8M 97 \nMALLOC guard page +> > 32K 8 \nMALLOC_NANO (reserved) 384.0M +> > 1 reserved VM address space (unallocated)\nSTACK GUARD +> > 56.0M 6 \nStack 10.5M 6 +> > \nVM_ALLOCATE 131.3M 13 \nVM_ALLOCATE +> > (reserved) 3.9G 1 reserved VM address space +> > (unallocated)\nWebKit Malloc 192.0M 5 +> > \n__CTF 824 1 \n__DATA +> > 35.2M 594 \n__DATA_CONST 37.3M 379 +> > \n__DATA_DIRTY 1712K 209 +> > \n__FONT_DATA 2352 1 \n__INFO_FILTER +> > 8 1 \n__LINKEDIT 175.4M +> > 30 \n__OBJC_RO 66.3M 1 \n__OBJC_RW +> > 2013K 1 \n__TEXT 617.8M 611 \ndyld +> > private memory 260K 2 \nmapped +> > file 239.4M 72 \nshared memory +> > 824K 26 \n=========== ======= ======= +> > \nTOTAL 7.2G 2359 \nTOTAL, minus +> reserved +> > VM space 3.0G 2359 \n", +> > "legacyInfo" : { +> > "threadTriggered" : { +> > "queue" : "com.apple.main-thread" +> > } +> > }, +> > "logWritingSignature" : "6cdfbb491c38e1280753887de64693565d8a493d", +> > "trialInfo" : { +> > "rollouts" : [ +> > { +> > "rolloutId" : "5ffde50ce2aacd000d47a95f", +> > "factorPackIds" : { +> > +> > }, +> > "deploymentId" : 240000372 +> > }, +> > { +> > "rolloutId" : "61675b89201f677a9a4cbd65", +> > "factorPackIds" : { +> > "HEALTH_FEATURE_AVAILABILITY" : "65a855f5f087695cfac03d1f" +> > }, +> > "deploymentId" : 240000112 +> > } +> > ], +> > "experiments" : [ +> > +> > ] +> > } +> > } +> > +> > -- +> > Carl Witthoft +> > +> > [[alternative HTML version deleted]] +> > +> > _______________________________________________ +> > R-SIG-Mac mailing list +> > R-SIG-Mac at r-project.org +> > https://stat.ethz.ch/mailman/listinfo/r-sig-mac +> +> -- +> Peter Dalgaard, Professor, +> Center for Statistics, Copenhagen Business School +> Solbjerg Plads 3, 2000 Frederiksberg, Denmark +> Phone: (+45)38153501 +> Office: A 4.23 +> Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com +> +> + + [[alternative HTML version deleted]] + + diff --git a/r-sig-mac/2024-May.txt b/r-sig-mac/2024-May.txt new file mode 100644 index 0000000..ca7d71f --- /dev/null +++ b/r-sig-mac/2024-May.txt @@ -0,0 +1,733 @@ +From @|mon@urb@nek @end|ng |rom R-project@org Fri May 3 03:10:37 2024 +From: @|mon@urb@nek @end|ng |rom R-project@org (Simon Urbanek) +Date: Fri, 3 May 2024 13:10:37 +1200 +Subject: [R-SIG-Mac] R 4.4 crashes loading dplyr +In-Reply-To: +References: + <02808911-83F7-4106-8FEA-E74C6CE0DCB2@gmail.com> + +Message-ID: <728A666F-7E77-4C94-A0F1-004C9427E30D@R-project.org> + +Carl, + +it shows that you apparently had some ancient version of magrittr installed way back from R 4.2.x. I have no idea why or how you got it, but update.packages(checkBuilt=TRUE) in R 4.4.0 should have fixed it. + +Cheers, +Simon + + + +> On 1/05/2024, at 12:32 AM, Carl Witthoft wrote: +> +> Thanks, Peter! The funny thing is that I had kept R 4.2 around in the +> Frameworks directory, but didn't expect a new installation of R4.4 to +> choose that path for libs. I removed R4.2 , then reinstalled R4.4 and now +> the correct libs are invoked. I guess some config macro file must have +> remained in the list of startup items. +> FWIW, after removing R4.2 but before reinstalling R4.4, I tried +> 'library(dplyr)' , which didn't crash but failed with the error msgs shown +> here. +> Error: package or namespace load failed for ?dplyr? in dyn.load(file, +> DLLpath = DLLpath, ...): +> unable to load shared object +> '/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so': +> +> dlopen(/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so, +> 0x0006): Library not loaded: +> /Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib +> Referenced from: +> /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so +> Reason: tried: +> '/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no +> such file), +> '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' +> (no such file), +> '/Library/Frameworks/R.framework/Versions/4.2/Resources/lib/libR.dylib' (no +> such file), '/usr/local/lib/libR.dylib' (no such file), +> '/usr/lib/libR.dylib' (no such file, not in dyld cac +> +> regards, +> Carl + + +From ethu||n @end|ng |rom um|ch@edu Fri May 3 14:26:52 2024 +From: ethu||n @end|ng |rom um|ch@edu (Elyse Thulin) +Date: Fri, 3 May 2024 08:26:52 -0400 +Subject: [R-SIG-Mac] Quanteda on mac with M2 advice +Message-ID: + +Hi, all, + +Can someone point me to any resources for figuring out how to run quanteda +on my m2 mac? + +Thanks! +Elyse + +-- +Elyse J. Thulin, Ph.D +Assistant Research Professor +University of Michigan +Institute for Firearm Injury Prevention +Department of Health Behavior and Health Education + +(e): ethulin at umich.edu +(w): elysethulin.github.io +Link to papers here + + + [[alternative HTML version deleted]] + + +From dw|n@em|u@ @end|ng |rom comc@@t@net Sat May 4 00:48:54 2024 +From: dw|n@em|u@ @end|ng |rom comc@@t@net (David Winsemius) +Date: Fri, 3 May 2024 15:48:54 -0700 +Subject: [R-SIG-Mac] Quanteda on mac with M2 advice +In-Reply-To: +References: +Message-ID: <7ac43efb-ec28-ba45-a580-515643fdc4aa@comcast.net> + + +On 5/3/24 05:26, Elyse Thulin wrote: +> Hi, all, +> +> Can someone point me to any resources for figuring out how to run quanteda +> on my m2 mac? + + +Seems like going to the "URL:" entry in the DESCRIPTION file would be +the obvious first place to try. + + +-- + +David. + +> +> Thanks! +> Elyse +> + + +From ken @end|ng |rom kjbe@th@|d@@u Sat May 4 07:49:18 2024 +From: ken @end|ng |rom kjbe@th@|d@@u (Ken Beath) +Date: Sat, 4 May 2024 15:49:18 +1000 +Subject: [R-SIG-Mac] Quanteda on mac with M2 advice +In-Reply-To: +References: +Message-ID: <92E3CAA2-0EB6-4085-8975-A9A92F10C357@kjbeath.id.au> + +You need to explain what particular part of running it doesn?t work. I?ve installed it on my M1 MacBook together with the extra packages in the Getting Started document, tried a simple example and everything works fine. If you look at their website https://quanteda.io it has a section Replications which shows how it can be used to perform some analyses from books. + +Ken + +> On 3 May 2024, at 10:26?PM, Elyse Thulin wrote: +> +> Hi, all, +> +> Can someone point me to any resources for figuring out how to run quanteda +> on my m2 mac? +> +> Thanks! +> Elyse +> +> -- +> Elyse J. Thulin, Ph.D +> Assistant Research Professor +> University of Michigan +> Institute for Firearm Injury Prevention +> Department of Health Behavior and Health Education +> +> (e): ethulin at umich.edu +> (w): elysethulin.github.io +> Link to papers here +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac + + + [[alternative HTML version deleted]] + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Sun May 5 16:27:19 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Sun, 5 May 2024 16:27:19 +0200 +Subject: [R-SIG-Mac] Knitting an Rmarkdown file fails for pdf +Message-ID: + +I have recently updated my Mac to R 4.4.0 and the latest version of RStudio. This may or may not be the reason that any Rmd files of mine with citations fail with the following error on knitting to pdf: + +! Undefined control sequence. +l.98 \NewDocumentCommand + \citeproctext{}{} + +Error: LaTeX failed to compile citeTest.tex. + +Knitting to html or to word work fine. Knitting to pdf without citations works as well. Does anyone have a solution? + +As a test file I have used the sample Rmd file from Posit with one citation added. + +Thanks for any help + +Antony + + +Professor (em.) Antony Unwin +Mathematics Institute, +University of Augsburg, +86135 Augsburg, Germany + + + + + [[alternative HTML version deleted]] + + +From pd@|gd @end|ng |rom gm@||@com Sun May 5 17:52:55 2024 +From: pd@|gd @end|ng |rom gm@||@com (peter dalgaard) +Date: Sun, 5 May 2024 17:52:55 +0200 +Subject: [R-SIG-Mac] Knitting an Rmarkdown file fails for pdf +In-Reply-To: +References: +Message-ID: <1267D96C-7DD5-4BC3-A4EB-1ACA9759B491@gmail.com> + +Hi Antony, + +The absence of \NewDocumentCommand could suggest that your LaTeX installation is too old. Some kind of path messup might also do it, I suppose. + +- Peter + +> On 5 May 2024, at 16:27 , Antony Unwin wrote: +> +> I have recently updated my Mac to R 4.4.0 and the latest version of RStudio. This may or may not be the reason that any Rmd files of mine with citations fail with the following error on knitting to pdf: +> +> ! Undefined control sequence. +> l.98 \NewDocumentCommand +> \citeproctext{}{} +> +> Error: LaTeX failed to compile citeTest.tex. +> +> Knitting to html or to word work fine. Knitting to pdf without citations works as well. Does anyone have a solution? +> +> As a test file I have used the sample Rmd file from Posit with one citation added. +> +> Thanks for any help +> +> Antony +> +> +> Professor (em.) Antony Unwin +> Mathematics Institute, +> University of Augsburg, +> 86135 Augsburg, Germany +> +> +> +> +> [[alternative HTML version deleted]] +> +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac + +-- +Peter Dalgaard, Professor, +Center for Statistics, Copenhagen Business School +Solbjerg Plads 3, 2000 Frederiksberg, Denmark +Phone: (+45)38153501 +Office: A 4.23 +Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Sun May 5 19:14:24 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Sun, 5 May 2024 19:14:24 +0200 +Subject: [R-SIG-Mac] Knitting an Rmarkdown file fails for pdf +In-Reply-To: <96b734e6-9bd6-4ebc-896f-e7f6e709d5db@gmail.com> +References: + <2b970d48-246b-4421-b38e-b3f9d30da481@gmail.com> + <6A2BAB84-D223-432A-AF15-EC8EAC871D0A@math.uni-augsburg.de> + <96b734e6-9bd6-4ebc-896f-e7f6e709d5db@gmail.com> +Message-ID: <66202D22-B8D2-4551-92F2-5CF5B40148F9@math.uni-augsburg.de> + +Thanks, Duncan, that solves that problem (and quickly!). + +Antony + + +> On 5 May 2024, at 18:33, Duncan Murdoch wrote: +> +> TeX Live 2015 is pretty old. Maybe an update would fix things. The R "tinytex" package installs a small version of TeX Live; it may be the easiest way to update. +> +> Duncan +> +> On 05/05/2024 11:25 a.m., Antony Unwin wrote: +>> The first line of my log file is: +>> This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015) (preloaded format=pdflatex 2015.10.28) +>>> On 5 May 2024, at 16:38, Duncan Murdoch wrote: +>>> +>>> On 05/05/2024 10:27 a.m., Antony Unwin wrote: +>>>> I have recently updated my Mac to R 4.4.0 and the latest version of RStudio. This may or may not be the reason that any Rmd files of mine with citations fail with the following error on knitting to pdf: +>>>> ! Undefined control sequence. +>>>> l.98 \NewDocumentCommand +>>>> \citeproctext{}{} +>>>> Error: LaTeX failed to compile citeTest.tex. +>>>> Knitting to html or to word work fine. Knitting to pdf without citations works as well. Does anyone have a solution? +>>>> As a test file I have used the sample Rmd file from Posit with one citation added. +>>>> Thanks for any help +>>>> Antony +>>> +>>> Can you tell which version of LaTeX it is using? +>>> +>>> Duncan Murdoch +>>> +> + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Sun May 5 19:15:40 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Sun, 5 May 2024 19:15:40 +0200 +Subject: [R-SIG-Mac] Knitting an Rmarkdown file fails for pdf +In-Reply-To: <1267D96C-7DD5-4BC3-A4EB-1ACA9759B491@gmail.com> +References: + <1267D96C-7DD5-4BC3-A4EB-1ACA9759B491@gmail.com> +Message-ID: + +Thanks, Peter. Duncan also suggested the age of my LaTeX installation might be the issue. + +Antony + +> On 5 May 2024, at 17:52, peter dalgaard wrote: +> +> Hi Antony, +> +> The absence of \NewDocumentCommand could suggest that your LaTeX installation is too old. Some kind of path messup might also do it, I suppose. +> +> - Peter +> +>> On 5 May 2024, at 16:27 , Antony Unwin wrote: +>> +>> I have recently updated my Mac to R 4.4.0 and the latest version of RStudio. This may or may not be the reason that any Rmd files of mine with citations fail with the following error on knitting to pdf: +>> +>> ! Undefined control sequence. +>> l.98 \NewDocumentCommand +>> \citeproctext{}{} +>> +>> Error: LaTeX failed to compile citeTest.tex. +>> +>> Knitting to html or to word work fine. Knitting to pdf without citations works as well. Does anyone have a solution? +>> +>> As a test file I have used the sample Rmd file from Posit with one citation added. +>> +>> Thanks for any help +>> +>> Antony +>> +>> +>> Professor (em.) Antony Unwin +>> Mathematics Institute, +>> University of Augsburg, +>> 86135 Augsburg, Germany +>> +>> +>> +>> +>> [[alternative HTML version deleted]] +>> +>> _______________________________________________ +>> R-SIG-Mac mailing list +>> R-SIG-Mac at r-project.org +>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac +> +> -- +> Peter Dalgaard, Professor, +> Center for Statistics, Copenhagen Business School +> Solbjerg Plads 3, 2000 Frederiksberg, Denmark +> Phone: (+45)38153501 +> Office: A 4.23 +> Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com +> + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Wed May 8 15:45:24 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Wed, 8 May 2024 15:45:24 +0200 +Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update +Message-ID: + +At the weekend I asked about a LaTex problem I had on the Mac and got an immediate solution, great! I have accordingly updated my LaTeX using tinytex and have a new problem. When I built my book with bookdown using the updated LaTeX there were a few small changes that I had to fix, some of which I think may have been due to a bit more space being given around tables, graphics, and lists. There was also a large change, the table of contents has extra spacing everywhere, so that now it needs 7 pages instead of 5. How can I get the old table of contents back? + +The book is for CRCPress and uses their krantz.cls LaTeX class file. + +Thanks, as always, for any help. + +Antony + +Professor (em.) Antony Unwin +Mathematics Institute, +University of Augsburg, +86135 Augsburg, Germany + +From m@rc_@chw@rtz @end|ng |rom me@com Wed May 8 16:37:35 2024 +From: m@rc_@chw@rtz @end|ng |rom me@com (Marc Schwartz) +Date: Wed, 08 May 2024 10:37:35 -0400 +Subject: [R-SIG-Mac] + Table of contents for book changed after LaTeX update +In-Reply-To: +References: +Message-ID: <29AC5009-4A4D-4E1A-B33F-B72FA259FACD@me.com> + +Hi Antony, + +Going back and looking at the thread over the weekend, I am wondering, if you did not uninstall the older version of TexLive/MacTeX, and there may be some conflicts with TinyTex, especially given the age of your old TexLive/MacTeX version. + +I found the following report, albeit, from 2021: + + https://github.com/rstudio/rmarkdown/issues/2172 + +that might support the hypothesis of a conflict between the two TeX installations. + +TeXLive/MacTex will typically install in /usr/local/texlive/XXXX, where XXXX is the year of the version. If that is still present, or there is more than one, and presuming that you want to stay with TinyTeX, I would remove the old installation(s). + +There will also be a texmf-local folder in the /usr/local/texlive folder and you should probably remove that as well. + +After the above, you may want to reboot your Mac, then reinstall TinyTeX, just to be sure that you then have a full and clean install. + +I install the full MacTeX version of TexLive from https://tug.org/mactex/, and just update the installation each year, removing the prior year's version, typically in the March/April timeframe on release. I also do frequent incremental updates of the installation using the TexLive utility app. + +Regards, + +Marc Schwartz + + +?-----Original Message----- +From: R-SIG-Mac > on behalf of Antony Unwin > +Date: Wednesday, May 8, 2024 at 9:46 AM +To: > +Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update + + +At the weekend I asked about a LaTex problem I had on the Mac and got an immediate solution, great! I have accordingly updated my LaTeX using tinytex and have a new problem. When I built my book with bookdown using the updated LaTeX there were a few small changes that I had to fix, some of which I think may have been due to a bit more space being given around tables, graphics, and lists. There was also a large change, the table of contents has extra spacing everywhere, so that now it needs 7 pages instead of 5. How can I get the old table of contents back? + + +The book is for CRCPress and uses their krantz.cls LaTeX class file. + + +Thanks, as always, for any help. + + +Antony + + +Professor (em.) Antony Unwin +Mathematics Institute, +University of Augsburg, +86135 Augsburg, Germany +_______________________________________________ +R-SIG-Mac mailing list +R-SIG-Mac at r-project.org +https://stat.ethz.ch/mailman/listinfo/r-sig-mac + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Wed May 8 17:52:54 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Wed, 8 May 2024 17:52:54 +0200 +Subject: [R-SIG-Mac] + Table of contents for book changed after LaTeX update +In-Reply-To: <29AC5009-4A4D-4E1A-B33F-B72FA259FACD@me.com> +References: + <29AC5009-4A4D-4E1A-B33F-B72FA259FACD@me.com> +Message-ID: <11DB24AA-8B3E-4A02-87BA-F5D98DFB5815@math.uni-augsburg.de> + +Marc, + +That makes a lot of sense, thanks for finding the rmarkdown issue and for your detailed instructions. It turned out I had three (!) TeXLive versions, the latest being 2015, and I have deleted these and the texmf-local folder. I also uninstalled TinyTeX, rebooted, and installed TinyTeX again. This has not solved my problem, but I suspect I have missed deleting something that should be deleted, perhaps /Library/TeX? + +Antony + + + +> On 8 May 2024, at 16:37, Marc Schwartz wrote: +> +> Hi Antony, +> +> Going back and looking at the thread over the weekend, I am wondering, if you did not uninstall the older version of TexLive/MacTeX, and there may be some conflicts with TinyTex, especially given the age of your old TexLive/MacTeX version. +> +> I found the following report, albeit, from 2021: +> +> https://github.com/rstudio/rmarkdown/issues/2172 +> +> that might support the hypothesis of a conflict between the two TeX installations. +> +> TeXLive/MacTex will typically install in /usr/local/texlive/XXXX, where XXXX is the year of the version. If that is still present, or there is more than one, and presuming that you want to stay with TinyTeX, I would remove the old installation(s). +> +> There will also be a texmf-local folder in the /usr/local/texlive folder and you should probably remove that as well. +> +> After the above, you may want to reboot your Mac, then reinstall TinyTeX, just to be sure that you then have a full and clean install. +> +> I install the full MacTeX version of TexLive from https://tug.org/mactex/, and just update the installation each year, removing the prior year's version, typically in the March/April timeframe on release. I also do frequent incremental updates of the installation using the TexLive utility app. +> +> Regards, +> +> Marc Schwartz +> +> +> ?-----Original Message----- +> From: R-SIG-Mac > on behalf of Antony Unwin > +> Date: Wednesday, May 8, 2024 at 9:46 AM +> To: > +> Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update +> +> +> At the weekend I asked about a LaTex problem I had on the Mac and got an immediate solution, great! I have accordingly updated my LaTeX using tinytex and have a new problem. When I built my book with bookdown using the updated LaTeX there were a few small changes that I had to fix, some of which I think may have been due to a bit more space being given around tables, graphics, and lists. There was also a large change, the table of contents has extra spacing everywhere, so that now it needs 7 pages instead of 5. How can I get the old table of contents back? +> +> +> The book is for CRCPress and uses their krantz.cls LaTeX class file. +> +> +> Thanks, as always, for any help. +> +> +> Antony +> +> +> Professor (em.) Antony Unwin +> Mathematics Institute, +> University of Augsburg, +> 86135 Augsburg, Germany +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac +> +> +> +> + + + [[alternative HTML version deleted]] + + +From m@rc_@chw@rtz @end|ng |rom me@com Wed May 8 18:24:32 2024 +From: m@rc_@chw@rtz @end|ng |rom me@com (Marc Schwartz) +Date: Wed, 08 May 2024 12:24:32 -0400 +Subject: [R-SIG-Mac] + Table of contents for book changed after LaTeX update +In-Reply-To: <11DB24AA-8B3E-4A02-87BA-F5D98DFB5815@math.uni-augsburg.de> +References: + <29AC5009-4A4D-4E1A-B33F-B72FA259FACD@me.com> + <11DB24AA-8B3E-4A02-87BA-F5D98DFB5815@math.uni-augsburg.de> +Message-ID: + +Hi Antony, + +Deleting the /Library/TeX folder tree would be another one to remove. There are also some links that may be in there that go back to the TexLive tree that presumably no longer exists. + +That being said, in checking the uninstall instructions for TexLive, there is a note of caution that if you have multiple TeX installations, others such as TinyTeX, may very well use that same /Library/TeX tree for their own purposes. + +Thus, if you do delete that tree for the sake of having a clean system, you may want to yet again, reinstall TinyTex. + +If these additional steps still do not resolve the issue, it may be prudent to post to the TinyTex issues forum on Github: + + https://github.com/rstudio/tinytex/issues + +perhaps with a reference back to that older rmarkdown issue, to see if any of the folks there might have some additional guidance. + +Regards, + +Marc + + + +From: Antony Unwin +Date: Wednesday, May 8, 2024 at 11:53?AM +To: Marc Schwartz +Cc: +Subject: Re: [R-SIG-Mac] Table of contents for book changed after LaTeX update + +Marc, + +That makes a lot of sense, thanks for finding the rmarkdown issue and for your detailed instructions. ?It turned out I had three (!) TeXLive versions, the latest being 2015, and I have deleted these and the texmf-local folder. ?I also uninstalled TinyTeX, rebooted, and installed TinyTeX again. ?This has not solved my problem, but I suspect I have missed deleting something that should be deleted, perhaps /Library/TeX? + +Antony? + + + + +On 8 May 2024, at 16:37, Marc Schwartz wrote: + +Hi Antony, + +Going back and looking at the thread over the weekend, I am wondering, if you did not uninstall the older version of TexLive/MacTeX, and there may be some conflicts with TinyTex, especially given the age of your old TexLive/MacTeX version. + +I found the following report, albeit, from 2021: + +?https://github.com/rstudio/rmarkdown/issues/2172 + +that might support the hypothesis of a conflict between the two TeX installations. + +TeXLive/MacTex will typically install in /usr/local/texlive/XXXX, where XXXX is the year of the version. If that is still present, or there is more than one, and presuming that you want to stay with TinyTeX, I would remove the old installation(s). + +There will also be a texmf-local folder in the /usr/local/texlive folder and you should probably remove that as well. + +After the above, you may want to reboot your Mac, then reinstall TinyTeX, just to be sure that you then have a full and clean install. + +I install the full MacTeX version of TexLive from https://tug.org/mactex/, and just update the installation each year, removing the prior year's version, typically in the March/April timeframe on release. I also do frequent incremental updates of the installation using the TexLive utility app. + +Regards, + +Marc Schwartz + + +?-----Original Message----- +From: R-SIG-Mac > on behalf of Antony Unwin > +Date: Wednesday, May 8, 2024 at 9:46 AM +To: > +Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update + + +At the weekend I asked about a LaTex problem I had on the Mac and got an immediate solution, great! I have accordingly updated my LaTeX using tinytex and have a new problem. When I built my book with bookdown using the updated LaTeX there were a few small changes that I had to fix, some of which I think may have been due to a bit more space being given around tables, graphics, and lists. There was also a large change, the table of contents has extra spacing everywhere, so that now it needs 7 pages instead of 5. How can I get the old table of contents back? + + +The book is for CRCPress and uses their krantz.cls LaTeX class file. + + +Thanks, as always, for any help. + + +Antony + + +Professor (em.) Antony Unwin +Mathematics Institute, +University of Augsburg, +86135 Augsburg, Germany +_______________________________________________ +R-SIG-Mac mailing list +R-SIG-Mac at r-project.org +https://stat.ethz.ch/mailman/listinfo/r-sig-mac + + +From unw|n @end|ng |rom m@th@un|-@ug@burg@de Wed May 8 19:37:26 2024 +From: unw|n @end|ng |rom m@th@un|-@ug@burg@de (Antony Unwin) +Date: Wed, 8 May 2024 19:37:26 +0200 +Subject: [R-SIG-Mac] + Table of contents for book changed after LaTeX update +In-Reply-To: +References: + <29AC5009-4A4D-4E1A-B33F-B72FA259FACD@me.com> + <11DB24AA-8B3E-4A02-87BA-F5D98DFB5815@math.uni-augsburg.de> + +Message-ID: + +Marc, + +Thanks again for the advice. After the deletion of /Library/TeX the double-spacing of the contents was still not sorted out. I?ll post to the TinyTex issues forum as you suggest. + +Regards + +Antony + +> On 8 May 2024, at 18:24, Marc Schwartz wrote: +> +> Hi Antony, +> +> Deleting the /Library/TeX folder tree would be another one to remove. There are also some links that may be in there that go back to the TexLive tree that presumably no longer exists. +> +> That being said, in checking the uninstall instructions for TexLive, there is a note of caution that if you have multiple TeX installations, others such as TinyTeX, may very well use that same /Library/TeX tree for their own purposes. +> +> Thus, if you do delete that tree for the sake of having a clean system, you may want to yet again, reinstall TinyTex. +> +> If these additional steps still do not resolve the issue, it may be prudent to post to the TinyTex issues forum on Github: +> +> https://github.com/rstudio/tinytex/issues +> +> perhaps with a reference back to that older rmarkdown issue, to see if any of the folks there might have some additional guidance. +> +> Regards, +> +> Marc +> +> +> +> From: Antony Unwin +> Date: Wednesday, May 8, 2024 at 11:53?AM +> To: Marc Schwartz +> Cc: +> Subject: Re: [R-SIG-Mac] Table of contents for book changed after LaTeX update +> +> Marc, +> +> That makes a lot of sense, thanks for finding the rmarkdown issue and for your detailed instructions. It turned out I had three (!) TeXLive versions, the latest being 2015, and I have deleted these and the texmf-local folder. I also uninstalled TinyTeX, rebooted, and installed TinyTeX again. This has not solved my problem, but I suspect I have missed deleting something that should be deleted, perhaps /Library/TeX? +> +> Antony +> +> +> +> +> On 8 May 2024, at 16:37, Marc Schwartz wrote: +> +> Hi Antony, +> +> Going back and looking at the thread over the weekend, I am wondering, if you did not uninstall the older version of TexLive/MacTeX, and there may be some conflicts with TinyTex, especially given the age of your old TexLive/MacTeX version. +> +> I found the following report, albeit, from 2021: +> +> https://github.com/rstudio/rmarkdown/issues/2172 +> +> that might support the hypothesis of a conflict between the two TeX installations. +> +> TeXLive/MacTex will typically install in /usr/local/texlive/XXXX, where XXXX is the year of the version. If that is still present, or there is more than one, and presuming that you want to stay with TinyTeX, I would remove the old installation(s). +> +> There will also be a texmf-local folder in the /usr/local/texlive folder and you should probably remove that as well. +> +> After the above, you may want to reboot your Mac, then reinstall TinyTeX, just to be sure that you then have a full and clean install. +> +> I install the full MacTeX version of TexLive from https://tug.org/mactex/, and just update the installation each year, removing the prior year's version, typically in the March/April timeframe on release. I also do frequent incremental updates of the installation using the TexLive utility app. +> +> Regards, +> +> Marc Schwartz +> +> +> ?-----Original Message----- +> From: R-SIG-Mac > on behalf of Antony Unwin > +> Date: Wednesday, May 8, 2024 at 9:46 AM +> To: > +> Subject: [R-SIG-Mac] Table of contents for book changed after LaTeX update +> +> +> At the weekend I asked about a LaTex problem I had on the Mac and got an immediate solution, great! I have accordingly updated my LaTeX using tinytex and have a new problem. When I built my book with bookdown using the updated LaTeX there were a few small changes that I had to fix, some of which I think may have been due to a bit more space being given around tables, graphics, and lists. There was also a large change, the table of contents has extra spacing everywhere, so that now it needs 7 pages instead of 5. How can I get the old table of contents back? +> +> +> The book is for CRCPress and uses their krantz.cls LaTeX class file. +> +> +> Thanks, as always, for any help. +> +> +> Antony +> +> +> Professor (em.) Antony Unwin +> Mathematics Institute, +> University of Augsburg, +> 86135 Augsburg, Germany +> _______________________________________________ +> R-SIG-Mac mailing list +> R-SIG-Mac at r-project.org +> https://stat.ethz.ch/mailman/listinfo/r-sig-mac +> +> +> +> +> +> + +