Skip to content

Commit 079d9fe

Browse files
actions-useractions-user
committed
New data collected at 2025-09-15_00-25-20
1 parent 837955b commit 079d9fe

5 files changed

Lines changed: 9504 additions & 0 deletions

File tree

‎r-devel/2025-September.txt‎

Lines changed: 245 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,245 @@
1+
From edd @end|ng |rom deb|@n@org Wed Sep 3 21:06:33 2025
2+
From: edd @end|ng |rom deb|@n@org (Dirk Eddelbuettel)
3+
Date: Wed, 3 Sep 2025 14:06:33 -0500
4+
Subject: [Rd] Suggested one word change for R-admin.texi
5+
Message-ID: <26808.37305.181737.645896@paul.eddelbuettel.com>
6+
7+
8+
The third bullet point in section A 3.1.4 'Shared BLAS' starts with 'This
9+
because less easy'; I suggest to change this to 'This became less easy':
10+
11+
edd at paul:~/svn/r-devel$ svn diff doc/manual/R-admin.texi
12+
Index: doc/manual/R-admin.texi
13+
===================================================================
14+
--- doc/manual/R-admin.texi (revision 88787)
15+
+++ doc/manual/R-admin.texi (working copy)
16+
@@ -4028,7 +4028,7 @@
17+
need to be found by the linker: this may need the library path to be
18+
changed in @file{@var{R_HOME}/etc/ldpaths}.
19+
20+
-This because less easy in 2025: swapping the BLAS is only possible to
21+
+This became less easy in 2025: swapping the BLAS is only possible to
22+
one compatible with the LAPACK in use. For the LAPACK shipped with @R{}
23+
4.5.0 that means one containing @code{dgemmtr} and @code{zgemmtr}, or
24+
configuring @R{} with @option{--with-2025blas}.
25+
edd at paul:~/svn/r-devel$
26+
27+
Best, Dirk
28+
29+
--
30+
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
31+
32+
33+
From Kurt@Horn|k @end|ng |rom wu@@c@@t Thu Sep 4 06:36:01 2025
34+
From: Kurt@Horn|k @end|ng |rom wu@@c@@t (Kurt Hornik)
35+
Date: Thu, 4 Sep 2025 06:36:01 +0200
36+
Subject: [Rd] Suggested one word change for R-admin.texi
37+
In-Reply-To: <26808.37305.181737.645896@paul.eddelbuettel.com>
38+
References: <26808.37305.181737.645896@paul.eddelbuettel.com>
39+
Message-ID: <26809.5937.265760.821119@hornik.net>
40+
41+
>>>>> Dirk Eddelbuettel writes:
42+
43+
Thanks: changed now.
44+
45+
Best
46+
-k
47+
48+
> The third bullet point in section A 3.1.4 'Shared BLAS' starts with 'This
49+
> because less easy'; I suggest to change this to 'This became less easy':
50+
51+
> edd at paul:~/svn/r-devel$ svn diff doc/manual/R-admin.texi
52+
> Index: doc/manual/R-admin.texi
53+
> ===================================================================
54+
> --- doc/manual/R-admin.texi (revision 88787)
55+
> +++ doc/manual/R-admin.texi (working copy)
56+
> @@ -4028,7 +4028,7 @@
57+
> need to be found by the linker: this may need the library path to be
58+
> changed in @file{@var{R_HOME}/etc/ldpaths}.
59+
60+
> -This because less easy in 2025: swapping the BLAS is only possible to
61+
> +This became less easy in 2025: swapping the BLAS is only possible to
62+
> one compatible with the LAPACK in use. For the LAPACK shipped with @R{}
63+
> 4.5.0 that means one containing @code{dgemmtr} and @code{zgemmtr}, or
64+
> configuring @R{} with @option{--with-2025blas}.
65+
> edd at paul:~/svn/r-devel$
66+
67+
> Best, Dirk
68+
69+
> --
70+
> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
71+
72+
> ______________________________________________
73+
> R-devel at r-project.org mailing list
74+
> https://stat.ethz.ch/mailman/listinfo/r-devel
75+
76+
77+
From he|g@@o|t @end|ng |rom gm@||@com Thu Sep 11 01:13:25 2025
78+
From: he|g@@o|t @end|ng |rom gm@||@com (helgasoft)
79+
Date: Wed, 10 Sep 2025 16:13:25 -0700
80+
Subject: [Rd] compiler::cmpfile output contains source code
81+
Message-ID: <a7fe8bef-806e-45b9-b938-ed5b4f2972b0@helgasoft.com>
82+
83+
Command?compiler::cmpfile(infile) outputs a binary (.Rc) file.
84+
The infile source code is contained in this output file.
85+
Is the source code required, and if not, is it possible to make it
86+
optional ?
87+
88+
89+
From @uny|ngk@| @end|ng |rom @jtu@edu@cn Thu Sep 11 03:09:25 2025
90+
From: @uny|ngk@| @end|ng |rom @jtu@edu@cn (=?gb2312?B?y+/Tor+t?=)
91+
Date: Thu, 11 Sep 2025 09:09:25 +0800 (CST)
92+
Subject: [Rd] [BUG?] S4 validity function not enforced during object
93+
creation in R 4.4.2
94+
Message-ID: <78022517.16035369.1757552965613.JavaMail.zimbra@sjtu.edu.cn>
95+
96+
97+
Dear R Core Team,
98+
I would like to report a possible bug or behavioral change in the S4 class system in R 4.4.2 regarding the validity function.
99+
Description of the issue:
100+
In previous versions of R, when the validity function of an S4 class returns a character string (i.e., an error message), the ?new() function would refuse to create the object and throw an error.
101+
However, in R 4.4.2, I found that ?new() creates the object successfully even when the validity function returns an error message. Only a manual call to ?validObject() triggers the error.
102+
Minimal reproducible example:
103+
104+
setClass('TestVital',
105+
slots = list(visit_type='character'),
106+
prototype = list(visit_type=''),
107+
validity = function(object){
108+
if(!object at visit_type %in% c('OP','IP')){
109+
return('??????')
110+
}
111+
TRUE
112+
})
113+
new('TestVital') # This should fail, but it succeeds in R 4.4.2
114+
validObject(new('TestVital')) # This correctly triggers the error
115+
116+
Session info:
117+
118+
R version 4.4.2 (2024-10-31)
119+
Platform: aarch64-apple-darwin20
120+
Running under: macOS Sequoia 15.6.1
121+
122+
Expected behavior:
123+
?new('TestVital') should fail and throw an error if the validity function returns a character string, as documented in the official R extensions manual.
124+
Actual behavior:
125+
?new('TestVital') creates the object even when the validity function returns an error message.
126+
Is this an intentional change in R 4.4.x, or is it a bug?
127+
Thank you for your attention.
128+
Best regards,
129+
Sun Yingkai
130+
131+
132+
From j@g@nmn2 @end|ng |rom gm@||@com Fri Sep 12 01:53:57 2025
133+
From: j@g@nmn2 @end|ng |rom gm@||@com (Mikael Jagan)
134+
Date: Thu, 11 Sep 2025 19:53:57 -0400
135+
Subject: [Rd] [BUG?] S4 validity function not enforced during object
136+
creation in R 4.4.2
137+
In-Reply-To: <mailman.55029.3.1757584802.51194.r-devel@r-project.org>
138+
References: <mailman.55029.3.1757584802.51194.r-devel@r-project.org>
139+
Message-ID: <ae877645-29bb-4dae-b839-74554b3fdb15@gmail.com>
140+
141+
Dear Yingkai,
142+
143+
The default method for 'initialize', which is called by 'new' in your example
144+
and is accessible as
145+
146+
> selectMethod("initialize", "ANY")
147+
148+
has always called 'validObject' *only if* it finds arguments matching '...',
149+
so the behaviour that you report is not a change from earlier behaviour.
150+
151+
The bug seems to be that you, the class author, defined a nonvirtual class
152+
with an invalid prototype, *not* that 'new' ignores invalid prototypes.
153+
154+
I added the following regression test in Matrix version 1.6-0 in order to
155+
catch exactly this mistake:
156+
157+
for (cl in c(names(getClassDef("Matrix")@subclasses),
158+
names(getClassDef("MatrixFactorization")@subclasses)))
159+
if (!isVirtualClass(def <- getClassDef(cl)))
160+
validObject(new(def))
161+
162+
One could argue that setClass(name, ...) should test validObject(new(name))
163+
before returning whenever it defines a nonvirtual class. But I can imagine
164+
false positives, e.g., if a class author documents that 'new' *must* be
165+
called with additional arguments, then the validity of the prototype seems
166+
inconsequential. Hence the test ought to be optional and probably (at least
167+
initially) disabled by default.
168+
169+
Mikael
170+
171+
172+
> Date: Thu, 11 Sep 2025 09:09:25 +0800 (CST)
173+
> From: =?gb2312?B?y+/Tor+t?=<sunyingkai at sjtu.edu.cn>
174+
>
175+
> Dear R Core Team,
176+
> I would like to report a possible bug or behavioral change in the S4 class system in R 4.4.2 regarding the validity function.
177+
> Description of the issue:
178+
> In previous versions of R, when the validity function of an S4 class returns a character string (i.e., an error message), the ?new() function would refuse to create the object and throw an error.
179+
> However, in R 4.4.2, I found that ?new() creates the object successfully even when the validity function returns an error message. Only a manual call to ?validObject() triggers the error.
180+
> Minimal reproducible example:
181+
>
182+
setClass('TestVital',
183+
> slots = list(visit_type='character'),
184+
> prototype = list(visit_type=''),
185+
> validity = function(object){
186+
> if(!object at visit_type %in% c('OP','IP')){
187+
> return('??????')
188+
> }
189+
> TRUE
190+
> })
191+
> new('TestVital') # This should fail, but it succeeds in R 4.4.2
192+
> validObject(new('TestVital')) # This correctly triggers the error
193+
>
194+
Session info:
195+
>
196+
R version 4.4.2 (2024-10-31)
197+
> Platform: aarch64-apple-darwin20
198+
> Running under: macOS Sequoia 15.6.1
199+
>
200+
Expected behavior:
201+
> ?new('TestVital') should fail and throw an error if the validity function returns a character string, as documented in the official R extensions manual.
202+
> Actual behavior:
203+
> ?new('TestVital') creates the object even when the validity function returns an error message.
204+
> Is this an intentional change in R 4.4.x, or is it a bug?
205+
> Thank you for your attention.
206+
> Best regards,
207+
> Sun Yingkai
208+
209+
210+
From |kry|ov @end|ng |rom d|@root@org Fri Sep 12 23:25:50 2025
211+
From: |kry|ov @end|ng |rom d|@root@org (Ivan Krylov)
212+
Date: Sat, 13 Sep 2025 00:25:50 +0300
213+
Subject: [Rd] compiler::cmpfile output contains source code
214+
In-Reply-To: <a7fe8bef-806e-45b9-b938-ed5b4f2972b0@helgasoft.com>
215+
References: <a7fe8bef-806e-45b9-b938-ed5b4f2972b0@helgasoft.com>
216+
Message-ID: <20250913002550.04d1c8de@Tarkus>
217+
218+
? Wed, 10 Sep 2025 16:13:25 -0700
219+
helgasoft <helgasoft at gmail.com> ?????:
220+
221+
> Command?compiler::cmpfile(infile) outputs a binary (.Rc) file.
222+
> The infile source code is contained in this output file.
223+
> Is the source code required, and if not, is it possible to make it
224+
> optional ?
225+
226+
The source references are optional. Since cmpfile() calls parse(),
227+
setting options(keep.source=FALSE) should prevent it from adding source
228+
references.
229+
230+
On the other hand, by calling compiler::disassemble() on the bytecode
231+
values, you will still be able to see the language objects from the
232+
file, so a somewhat lossy representation of the source code is still
233+
present. These language objects are used at least for error handling
234+
and sometimes for internal consistency checks [*].
235+
236+
What's your use case?
237+
238+
--
239+
Best regards,
240+
Ivan
241+
242+
[*]
243+
https://coolbutuseless.github.io/book/rbytecodebook/15-stored-expressions.html
244+
245+

0 commit comments

Comments
 (0)