[Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Andrew Hart via R-devel]

Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this 
is the right place to ask about it. If it's not, I'm hoping someone can 
point me in the right direction.


I'm blind and have been using R for about 11 years now. The base build 
available on CRAN is quite accessible and works pretty well with 
screen-reading software such as JAWS for Windows and NVDA. R-studio is 
not accessible which appears to have something to do with the version of 
QT it uses, but that's not relevant as I don't use it.


Recently I installed R 4.2.1 (I tend to upgrade two or three times a 
year and this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest 
version more or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R 
cursor and behaves as though the cursor is near the top left of the R 
application window. Practically, this means I can't tell what characters 
I'm passing over when cursoring left and right, nor can I hear what 
character is being deleted when the backspace is pressed. Most 
importantly, I can't tell where the insertion point is. This is a major 
regression in the ability to work with and edit the command line in the 
R console. There are ways of actually viewing the command line but the 
way I work is frequently calling up a previous command and making a 
change so as to not have to type the whole command again.


I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out 
exactly when things went awry and the issue first appeared in R 4.2.0.
Looking through the release notes, the only things mentioned that seem 
likely to be relevant are the following:


• R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle 
had a different layout and can no longer be used.


and

• R uses UTF-8 as the native encoding on recent Windows systems (at 
least Windows 10 version 1903, Windows Server 2022 or Windows Server 
1903). As a part
of this change, R uses UCRT as the C runtime. UCRT should be installed 
manually on systems older than Windows 10 or Windows Server 2016 before 
installing

R.

I can't really see how changing to utf-8 as the native encoding would 
produce the behaviour I'm seeing, so I am guessing that the change in 
TCL/TK might be the culprit.


I'm hoping that someone will be able to help shed some light on what's 
going on here.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Ben Bolker]

  There was a long apparently related thread back in May:

https://stat.ethz.ch/pipermail/r-devel/2022-May/081708.html

but that problem was supposedly patched in 4.2.1 ...


On 2022-09-22 9:48 a.m., Andrew Hart via R-devel wrote:
Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this 
is the right place to ask about it. If it's not, I'm hoping someone can 
point me in the right direction.


I'm blind and have been using R for about 11 years now. The base build 
available on CRAN is quite accessible and works pretty well with 
screen-reading software such as JAWS for Windows and NVDA. R-studio is 
not accessible which appears to have something to do with the version of 
QT it uses, but that's not relevant as I don't use it.


Recently I installed R 4.2.1 (I tend to upgrade two or three times a 
year and this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest 
version more or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R 
cursor and behaves as though the cursor is near the top left of the R 
application window. Practically, this means I can't tell what characters 
I'm passing over when cursoring left and right, nor can I hear what 
character is being deleted when the backspace is pressed. Most 
importantly, I can't tell where the insertion point is. This is a major 
regression in the ability to work with and edit the command line in the 
R console. There are ways of actually viewing the command line but the 
way I work is frequently calling up a previous command and making a 
change so as to not have to type the whole command again.


I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out 
exactly when things went awry and the issue first appeared in R 4.2.0.
Looking through the release notes, the only things mentioned that seem 
likely to be relevant are the following:


• R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle 
had a different layout and can no longer be used.


and

• R uses UTF-8 as the native encoding on recent Windows systems (at 
least Windows 10 version 1903, Windows Server 2022 or Windows Server 
1903). As a part
of this change, R uses UCRT as the C runtime. UCRT should be installed 
manually on systems older than Windows 10 or Windows Server 2016 before 
installing

R.

I can't really see how changing to utf-8 as the native encoding would 
produce the behaviour I'm seeing, so I am guessing that the change in 
TCL/TK might be the culprit.


I'm hoping that someone will be able to help shed some light on what's 
going on here.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[peter dalgaard]

Tomas Kalibera has related that he has some scars from fighting with some 
unexpected interactions between UTF-8 and the GraphApp library that is used for 
RGui and I think he said that screen readers were involved. I wouldn't be 
surprised if this is a leftover issue. (This is obviously a kind of issue that 
non-blind users don't "see" :-) ).

Would it work for you to use the terminal application (the "DOS box", or 
whatever it is called these days) until the issue gets fixed?

In general, I would expect your go-to guy for blindness-related issues to be 
Jonathon Godfrey (cc'ed). Perhaps he can offer some advice.

-pd
 

> On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel  
> wrote:
> 
> Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this is 
> the right place to ask about it. If it's not, I'm hoping someone can point me 
> in the right direction.
> 
> I'm blind and have been using R for about 11 years now. The base build 
> available on CRAN is quite accessible and works pretty well with 
> screen-reading software such as JAWS for Windows and NVDA. R-studio is not 
> accessible which appears to have something to do with the version of QT it 
> uses, but that's not relevant as I don't use it.
> 
> Recently I installed R 4.2.1 (I tend to upgrade two or three times a year and 
> this time I was jumping from R 4.1.2 to 4.2.1).
> However, I've encountered a serious problem which makes the latest version 
> more or less unusable for doing any kind of serious work.
> The issue is that the screen-reading software is unable to locate the R 
> cursor and behaves as though the cursor is near the top left of the R 
> application window. Practically, this means I can't tell what characters I'm 
> passing over when cursoring left and right, nor can I hear what character is 
> being deleted when the backspace is pressed. Most importantly, I can't tell 
> where the insertion point is. This is a major regression in the ability to 
> work with and edit the command line in the R console. There are ways of 
> actually viewing the command line but the way I work is frequently calling up 
> a previous command and making a change so as to not have to type the whole 
> command again.
> 
> I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out exactly 
> when things went awry and the issue first appeared in R 4.2.0.
> Looking through the release notes, the only things mentioned that seem likely 
> to be relevant are the following:
> 
> • R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle had a 
> different layout and can no longer be used.
> 
> and
> 
> • R uses UTF-8 as the native encoding on recent Windows systems (at least 
> Windows 10 version 1903, Windows Server 2022 or Windows Server 1903). As a 
> part
> of this change, R uses UCRT as the C runtime. UCRT should be installed 
> manually on systems older than Windows 10 or Windows Server 2016 before 
> installing
> R.
> 
> I can't really see how changing to utf-8 as the native encoding would produce 
> the behaviour I'm seeing, so I am guessing that the change in TCL/TK might be 
> the culprit.
> 
> I'm hoping that someone will be able to help shed some light on what's going 
> on here.
> 
> Thanks a lot,
> Andrew.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Duncan Murdoch]

On 22/09/2022 9:48 a.m., Andrew Hart via R-devel wrote:

Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this
is the right place to ask about it. If it's not, I'm hoping someone can
point me in the right direction.

I'm blind and have been using R for about 11 years now. The base build
available on CRAN is quite accessible and works pretty well with
screen-reading software such as JAWS for Windows and NVDA. R-studio is
not accessible which appears to have something to do with the version of
QT it uses, but that's not relevant as I don't use it.


I believe RStudio is in the process of moving away from QT to Electron. 
 I don't know when the non-QT version will be released (if not 
already), but you might want to investigate that if Rgui doesn't work out.


Duncan Murdoch


Recently I installed R 4.2.1 (I tend to upgrade two or three times a
year and this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest
version more or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R
cursor and behaves as though the cursor is near the top left of the R
application window. Practically, this means I can't tell what characters
I'm passing over when cursoring left and right, nor can I hear what
character is being deleted when the backspace is pressed. Most
importantly, I can't tell where the insertion point is. This is a major
regression in the ability to work with and edit the command line in the
R console. There are ways of actually viewing the command line but the
way I work is frequently calling up a previous command and making a
change so as to not have to type the whole command again.

I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out
exactly when things went awry and the issue first appeared in R 4.2.0.
Looking through the release notes, the only things mentioned that seem
likely to be relevant are the following:

• R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle
had a different layout and can no longer be used.

and

• R uses UTF-8 as the native encoding on recent Windows systems (at
least Windows 10 version 1903, Windows Server 2022 or Windows Server
1903). As a part
of this change, R uses UCRT as the C runtime. UCRT should be installed
manually on systems older than Windows 10 or Windows Server 2016 before
installing
R.

I can't really see how changing to utf-8 as the native encoding would
produce the behaviour I'm seeing, so I am guessing that the change in
TCL/TK might be the culprit.

I'm hoping that someone will be able to help shed some light on what's
going on here.

Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Toby Hocking]

Another option is to use https://emacspeak.sourceforge.net/ (version of
emacs editor/ide which can speak letters/words/lines -- has a blind
maintainer) with https://ess.r-project.org/ (interface for editing and
running R code from within emacs)

On Thu, Sep 22, 2022 at 9:42 AM Duncan Murdoch 
wrote:

> On 22/09/2022 9:48 a.m., Andrew Hart via R-devel wrote:
> > Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this
> > is the right place to ask about it. If it's not, I'm hoping someone can
> > point me in the right direction.
> >
> > I'm blind and have been using R for about 11 years now. The base build
> > available on CRAN is quite accessible and works pretty well with
> > screen-reading software such as JAWS for Windows and NVDA. R-studio is
> > not accessible which appears to have something to do with the version of
> > QT it uses, but that's not relevant as I don't use it.
>
> I believe RStudio is in the process of moving away from QT to Electron.
>   I don't know when the non-QT version will be released (if not
> already), but you might want to investigate that if Rgui doesn't work out.
>
> Duncan Murdoch
> >
> > Recently I installed R 4.2.1 (I tend to upgrade two or three times a
> > year and this time I was jumping from R 4.1.2 to 4.2.1).
> > However, I've encountered a serious problem which makes the latest
> > version more or less unusable for doing any kind of serious work.
> > The issue is that the screen-reading software is unable to locate the R
> > cursor and behaves as though the cursor is near the top left of the R
> > application window. Practically, this means I can't tell what characters
> > I'm passing over when cursoring left and right, nor can I hear what
> > character is being deleted when the backspace is pressed. Most
> > importantly, I can't tell where the insertion point is. This is a major
> > regression in the ability to work with and edit the command line in the
> > R console. There are ways of actually viewing the command line but the
> > way I work is frequently calling up a previous command and making a
> > change so as to not have to type the whole command again.
> >
> > I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out
> > exactly when things went awry and the issue first appeared in R 4.2.0.
> > Looking through the release notes, the only things mentioned that seem
> > likely to be relevant are the following:
> >
> > • R uses a new 64-bit Tcl/Tk bundle. The previous 32-bit/64-bit bundle
> > had a different layout and can no longer be used.
> >
> > and
> >
> > • R uses UTF-8 as the native encoding on recent Windows systems (at
> > least Windows 10 version 1903, Windows Server 2022 or Windows Server
> > 1903). As a part
> > of this change, R uses UCRT as the C runtime. UCRT should be installed
> > manually on systems older than Windows 10 or Windows Server 2016 before
> > installing
> > R.
> >
> > I can't really see how changing to utf-8 as the native encoding would
> > produce the behaviour I'm seeing, so I am guessing that the change in
> > TCL/TK might be the culprit.
> >
> > I'm hoping that someone will be able to help shed some light on what's
> > going on here.
> >
> > Thanks a lot,
> > Andrew.
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Tomas Kalibera]

On 9/22/22 18:24, peter dalgaard wrote:

Tomas Kalibera has related that he has some scars from fighting with some unexpected 
interactions between UTF-8 and the GraphApp library that is used for RGui and I think he 
said that screen readers were involved. I wouldn't be surprised if this is a leftover 
issue. (This is obviously a kind of issue that non-blind users don't "see" :-) 
).


Yes, that's almost surely related. GraphApp uses very different code for 
handling Windows messages in a multi-byte locale and single-byte locale, 
so switching to UTF-8 changed a lot. The multi-byte version hasn't been 
used that much before, and hence a number of bugs showed up after the 
switch.



Would it work for you to use the terminal application (the "DOS box", or 
whatever it is called these days) until the issue gets fixed?

In general, I would expect your go-to guy for blindness-related issues to be 
Jonathon Godfrey (cc'ed). Perhaps he can offer some advice.


There were two issues reported already with other software controlling a 
running window of Rgui, one was fixed in 4.2.1 (SendInput() for text 
injection didn't work in a multi-byte locale). Another hopefully was 
fixed in the application (it was using WM_CHAR messages to inject text, 
but that is not the right way to do this and fixing that to work as 
before would bee too difficult; the way recommended by Microsoft is 
SendInput, which now works).


It would be good if we could debug and fix this, on either end. For that 
we need to find out how the concrete screen reading applications 
communicate with Rgui window. Ideally I would have a tiny example which 
I could build and run on my Windows machine, without any special 
hardware, which would demonstrate the problem. Or, at least if the 
source code is available and we could have a look. Even if the 
application is closed source, the Windows messages could be captured by 
some tracing software to debug the protocol, and one could try writing 
an example/reproduction of the problem based on that.


Hopefully someone reading this could help with producing such an 
example, and then I could try investigating why it stopped working and 
fix, if possible.


In principle, we cannot yet assume that all Windows systems are new 
enough to support UTF-8 as the system encoding (also called ACP in 
Windows), so R support for running on Windows in a single-byte locale 
still cannot be removed, it will almost surely stay at least in 4.3. So, 
what I could definitely do is create an alternative build of Rgui which 
will use single-byte locale (like the older versions of R) even on new 
Windows systems. That alternatively build might be removed later if we 
decide to require UTF-8, but, temporarily it might help. Still, I hope 
we can debug and fix this to work properly when R is running with UTF-8 
as the native encoding.


I hope for now you can get away with 4.1.3. In principle, building Rgui 
to run R using single-byte locale is trivial (one just changes the 
manifest file for Rgui), so if a temporary solution was needed very 
fast, one can just do that and have a custom build before any new R 
release. Also, well, an older version of Windows 10 (or even older 
Windows) that don't support UTF-8 as the native encoding would do the same.


Best
Tomas




-pd
  


On 22 Sep 2022, at 15:48 , Andrew Hart via R-devel  
wrote:

Hi. I'm having an issue with R 4.2.1 on Windows but I'm not sure if this is the 
right place to ask about it. If it's not, I'm hoping someone can point me in 
the right direction.

I'm blind and have been using R for about 11 years now. The base build 
available on CRAN is quite accessible and works pretty well with screen-reading 
software such as JAWS for Windows and NVDA. R-studio is not accessible which 
appears to have something to do with the version of QT it uses, but that's not 
relevant as I don't use it.

Recently I installed R 4.2.1 (I tend to upgrade two or three times a year and 
this time I was jumping from R 4.1.2 to 4.2.1).
However, I've encountered a serious problem which makes the latest version more 
or less unusable for doing any kind of serious work.
The issue is that the screen-reading software is unable to locate the R cursor 
and behaves as though the cursor is near the top left of the R application 
window. Practically, this means I can't tell what characters I'm passing over 
when cursoring left and right, nor can I hear what character is being deleted 
when the backspace is pressed. Most importantly, I can't tell where the 
insertion point is. This is a major regression in the ability to work with and 
edit the command line in the R console. There are ways of actually viewing the 
command line but the way I work is frequently calling up a previous command and 
making a change so as to not have to type the whole command again.

I Went and installed R 4.1.3 and R 4.2.0 in an attempt to find out exactly when 
things went awry and the issue first appeared in R 4.2.0.
Look

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Andrew Hart via R-devel]

On 22/09/2022 16:42, Toby Hocking wrote:
Another option is to use https://emacspeak.sourceforge.net/ 
 (version of emacs editor/ide which 
can speak letters/words/lines -- has a blind maintainer) with 
https://ess.r-project.org/  (interface for 
editing and running R code from within emacs)


Thanks everyone for all the suggestions. Of course, the optimal solution 
would be to figure out what is going on in Rgui, but, as is always the 
case, the blind user use case is a fairly niche one. I appreciate all 
the suggestions for finding an immediate solution to my problem.
I don't use any kind of IDE for working with R since I simply haven't 
found one that is accessible or that i understand how to use. There is a 
plug-in for the Eclipse IDE I installed a few years ago, but I didn't 
understand the first thing about how it was to be used. So I've just 
always worked with an editor open in one Window and R in another,
working interactively in R or bouncing over to the editor for more 
complex things and sourcing code into R as necessary. However, I only 
use the R console in Rgui. I went and had a look at Rterm, which I have 
never used on Windows; I've only ever used it when ssh-ing into Linux 
systems to use R. However, I've just found out that Rterm does a number 
of fairly important things that probably mean I can just use it instead 
of Rgui:

1. You can paste from the clipboard into the Rterm prompt;
2. It has a command history;
3. If you plot something, it opens a Window to draw the plot (I never 
realised it could do this and had always assumed Rgui was needed for 
this); and
4. It opens the HTML help if you ask for help on windows. I only ever 
saw it display text help on Linux, but I was logged in remotely. 
Text-based help is fine when ssh-ing into a machine, but HTML help is 
much nicer to read and navigate.


I think I'll just switch over to Rterm for a while, but I can also check 
out ess, which I wasn't aware of.


Thanks a lot,
Andrew.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with accessibility in R 4.2.0 and 4.2.1.

[Tomas Kalibera]

On 9/22/22 23:13, Jonathan Godfrey wrote:

Hello all,

I can confirm Andrew's assessment of the situation for screen reader users 
(both JAWS and NVDA) for R GUI version 4.2.1; I don't intend to go back and 
verify how/when the problem first arose though.

The situation is not new, or at least the same experience was evident well 
before now. When I started using R around 2005/6, the experience we now see 
today was how I found the GUI then. I investigated the terminal which was a 
huge success and never looked back.

I tracked how the R GUI was going because my students would be using it, and at 
some stage, the way the GUI cursor behaved changed. If I recall correctly, the 
physical appearance of the cursor also altered at the same time. I still update 
versions regularly to stay one step of my students (all sighted) but because no 
one uses the R GUI, my efforts to trace its behaviour have been dwindling over 
the last five or so years. I don't need to check the RStudio behaviour because 
I can't, my colleagues are doing so, and I know it won't change for blind 
people anytime soon.

The terminal has behaved consistently all that time. It has some minor 
differences between JAWS and NVDA, but the user knows what their screen reader 
is doing so the differences have relatively minor impact. It remains how I use 
R and therefore what I recommend for other blind users. N.B. I also strongly 
recommend R markdown files over R scripts.

The experience in the GUI was human dependent, with the choice of screen reader 
and the skill level of the users with their screen reader both having an impact 
on the overall user experience. For many years, NVDA users were better off in 
the GUI than in the terminal, while most JAWS users were happier in the 
terminal. It has been fairly fluid though so my advice has been to try, using 
the existing skills and screen reader, but to be prepared to revert to the 
terminal fairly quickly.

Minor variations in the interactions of R GUI and the various screen readers 
mean the difference between JAWS and NVDA were very similar prior to v4.2.0 to 
the extent that I would say the experience had converged quite nicely.

RStudio has not made any significant progress in making its IDE more 
accessible, and I fear that it never will. I have tested other front ends and 
none have yet met accessibility standards. The problem with most of the front 
ends is that they are using development toolkits (such as QT) that do not speak 
with screen readers straight out of the box. I mentioned this in my R Journal 
article back in 2013.

I fear that the development toolkit problem is what compromises accessibility 
of R GUI too. In a discussion I had with Duncan at UseR 2015, it was obvious to 
me that nothing  intentional had been done to the R GUI to improve my initial 
experience to the situation Andrew has been enjoying. For that reason, I 
suspect that there is room for something different in the background, as 
against any explicit action taken by the R developments, which have 
(unfortunately) taken us backwards.

Andrew: I am confident you can move to the terminal without requiring help, but 
grabbing the latest development version of BrailleR off GitHub will give you 
some functions that will save a bit of effort. We might arrange a voice call 
next week for an ongoing discussion.

Tomas: I'm not able to help with your suggestion, mainly because I don't 
understand the nuts and bolts of it. I do believe though that the cursor focus 
is a critical factor, but that the cursor being used by the screen reader 
software is different to the cursor being used by the sighted users. When I 
switch from the active cursor to the screen readers' review mode, the screen 
readers both take me back to the top left of the window under the menu bar. Has 
anything changed in the visual appearance of the cursor from v4.1.3 to v4.2.0? 
I ask because it is the symptom.


Dear Jonathan,

thanks for all the background. There was no change in Rgui/GraphApp 
meant to change anything related to the cursor in 4.2.0 (neither at 
least in the last 5 years). There have only been very few changes, 
majority of them to fix encoding issues. But, as you write, these things 
can happen indirectly, and the switch to 4.2.0 has already woken up many 
(as GraphApp then uses different code than before, and as Windows 
sometimes support UTF-8 in surprising ways - it is a very new feature 
and making the old Windows component accept it properly is probably 
difficult). One of them was actually also reported by a blind user (I 
broke the search/replace in the script editor, already fixed).


Best
Tomas

Peter: Thank you very much for actively bringing me into this thread. I don't 
know why I hadn't seen Andrew's first message given I get other list traffic.

Jonathan


-Original Message-
From: peter dalgaard 
Sent: Friday, 23 September 2022 4:24 am
To: Andrew Hart 
Cc: R-devel@r-project.org; Tomas Kalibera ; Jonathan