[Bioc-devel] Bioconductor Code of Conduct Reminder

[Anna Quaglieri]

Hello Bioconductor Community,

It is important to reflect on the importance of upholding Bioconductor
values often:
 our
commitment to an open approach to science, collaboration, diversity,
inclusivity, and a welcoming environment is at the core of our community.

The Bioconductor Code of Conduct serves as a guiding light, ensuring that
we maintain a supportive space for all. Let's continue working together to
nurture an environment that encourages the exchange of ideas and fosters
collective growth.

Everybody can reach the Code of Conduct committee
 if you consider
that some situation doesn’t reflect these values.

Thank you for your dedication to the Bioconductor community.

Anna
On Behalf of the Bioconductor Code Of Conduct Committee

-- 
*Anna Quaglieri, PhD (she/her)*
Data Scientist @ Mass Dynamics
Co-Chair @ Bioconductor Code Of Conduct Committee

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

[Rd] `sort` hanging without R_CheckUserInterrupt()

[Aidan Lakshman]

Hi everyone,

Just a quick question/problem I encountered, wanted to make sure this is known 
behavior. Running `sort` on a long vector can take quite a bit of time, and I 
found today that there don’t seem to be any calls to `R_CheckUserInterrupt()` 
during execution. Calling something like `sort((2^31):1)` takes good bit of 
time to run on my machine and is uninterruptable without force-terminating the 
entire R session.

There doesn’t seem to be any mention in the help files that this method is 
uninterruptable. All the methods called from `sortVector` in `src/main/sort.c` 
lack checks for user interrupts as well.

My main question is, is this known behavior? Is it worth including a warning in 
the help file? I don’t doubt that including a bunch of `R_CheckUserInterrupt()` 
calls would really hurt performance, but it may be possible to add an 
occasional call if `sort` is called on a long vector.

This may not even be a problem that affects people, which is my main reason for 
inquiring.

-Aidan



---
Aidan Lakshman (he/him)
www.AHL27.com

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

Re: [Bioc-devel] Fw: MungeSumstats Bioconductor

[alan murphy]

Hey Herve,

Thanks for this, I'm going to implement that now. One thing I wondered, is it 
only the tests in the longtest/ folder that run on these weekly builds or both 
those and the tests in test/? I'm wondering should I duplicate the tests in 
both folders that I want to run in both?

Cheers,
Alan.

From: Herv� Pag�s 
Sent: Tuesday 6 February 2024 18:58
To: alan murphy ; Bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] Fw: MungeSumstats Bioconductor


Hi Alan,

The specs of the Linux servers have not changed.

However we've recently observed some of these random kills by the Linux kernel 
for a couple of other packages, and we started an application to get funding to 
increase the amount of RAM on these machines.

These random kills are a desperate attempt by the Linux kernel to keep the 
machine alive when it's under extremely high load and running out of resources. 
Unfortunately this is not something that anybody will be able to easily 
reproduce as it only happens under special circumstances e.g. during the daily 
builds when dozens of packages are being checked simultaneously.

Regardless of whether we'll manage to increase the memory on the Linux servers, 
it seems to me that the most memory-hungry unit tests in MungeSumstats would be 
a better fit for the long tests. These tests are run once a week instead of 
daily, and use less workers (4 instead of 28). This means that each package has 
access to more resources.

See https://contributions.bioconductor.org/long-tests.html for how to set up 
the long tests in your package.

Let me know if you have questions or need help with this.

Best,

H.

On 2/2/24 09:14, alan murphy wrote:

Hi,

I'm the maintainer of the MungeSumstats package which is currently failing on 
the devel nebbiolo1 Linux platform because of RAM requirements of the unit 
tests. These tests use large reference datasets (like 
BSgenome.Hsapiens.1000genomes.hs37d5::BSgenome.Hsapiens.1000genomes.hs37d5) 
which cause the issue, e.g. from the output of the devel linux 
test:

```

Validating RSIDs of 92 SNPs using BSgenome::snpsById...
Killed

```
which is from this function: 
https://github.com/neurogenomics/MungeSumstats/blob/cccf77b2249f52be59fe1749f13a386ffaaae528/R/load_ref_genome_data.R#L49

I would like to keep these units tests as they are very important for me to 
know if things have gone wrong. I can't scale down the RAM usage, it is only 
using a few rows of data as it, the issue is that the reference sets are 
massive rather than the actual set being tested. I currently don't have a lot 
of these tests set to run on windows/mac platforms so I rely on the Linux 
machines to run this. I am not sure what has changed but a few releases back, 
the same tested were not causing this issue and would complete on linux - has 
the machine spec changed? Is there any chance RAM could be increased for these 
tests or is there a way to specify not to run the specific unit tests on the 
Bioconductor server so I can at least keep these for my github actions 
workflows? See below for the automated message I got about these errors.

[[elided Hotmail spam]]

Thanks,
Alan.

From: CoreTeam Bioconductor 

Sent: Friday 2 February 2024 16:43
To: alanmurp...@hotmail.com 

Subject: MungeSumstats Bioconductor

Hello Package Maintainer,

We would like to bring to your attention that your package is failing in devel 
on the linux platform. This is very problematic. Please investigate the issues 
and fix the package to avoid deprecation.

https://bioconductor.org/checkResults/devel/bioc-LATEST/


If you have further questions or concerns please reach out on the 
bioc-devel@r-project.org

We appreciate your quick attention to this matter

Cheers,
On behalf of the Bioconductor Core Team

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


--
Herv� Pag�s

Bioconductor Core Team
hpages.on.git...@gmail.com


[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [R-pkg-devel] Conversion failure in 'mbcsToSbcs'

[Package Maintainer]

Dear Ivan and all:

Thank you for this helpful advice. I have received confirmation that
the package is now on its way to CRAN.

Many thanks again.

LAR

On Wed, Feb 21, 2024 at 12:45 PM Ivan Krylov  wrote:
>
> В Wed, 21 Feb 2024 12:29:02 +
> Package Maintainer  пишет:
>
> > Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
> >  chunk 58 (label = plotCBText)
>
> In order to use the non-standard graphics device, the chunk must
> set the option fig=TRUE. Otherwise, when something calls
> graphics::strwidth('Lubomír Kubáček', "inches"), R notices that no
> graphics device is active and creates a default one, which happens to
> be pdf() and has all these problems. With fig=TRUE, Sweave will
> initialise the cairo_pdf() device first, and then graphics::strwidth()
> will use the existing device, avoiding the error.
>
> --
> Best regards,
> Ivan

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

Re: [Rd] Tcl socket server (tcltk) does not work any more on R 4.3.2

[peter dalgaard]

The obvious problem with

while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;

is that once something does the http server thing, you'll be running 
Tcl_DoOneEvent max_ev times, _every_ time you hit TclSpinLoop.

I wonder it we could some sort of hybrid between this and Tcl_ServiceAll()? 
Like, calling Tcl_DoOneEvent once before/after Tcl_ServiceAll().

- Peter

> On 21 Feb 2024, at 17:04 , Tomas Kalibera  wrote:
> 
> 
> On 2/21/24 08:01, webmail.gandi.net wrote:
>> Thank you, Ivan for this investigation. I inspected the R changes file 
>> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing 
>> about this. I should inspect the sources too!
>> 
>> It could possibly break other Tcl/Tk related stuff. The doc about 
>> Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when 
>> Tcl is used from an external program, Tcl_ServiceAll should be used in its 
>> event loop instead of Tcl_DoOneEvent (and the change in the latest R 
>> versions goes in that direction). But in the other hand, it is indicated 
>> that Tcl_ServiceAll does not always handle all Tcl events and extra 
>> Tcl_DoOneEvent should be called in this case. I think we spotted one case 
>> where Tcl_ServiceAll is not doing its job correctly. There may be others.
>> 
>> Since the {tcltk} package was working fine with  "while 
>> (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is a clear 
>> performance enhancement with "while (i-- && Tcl_ServiceAll())", it would 
>> perhaps be wise to revert this back.
> 
> Yes, for now I've done that in R-devel. The Tcl documentation is really hard 
> to follow, but debugging reveals that Tcl_ServiceAll() doesn't queue new 
> events, as also Ivan reports.
> 
> Tomas
> 
>> 
>> Indeed, when I use this on the server side with R 4.3.2:
>> 
>> library(tcltk)
>> cmd <- r"(
>>  proc accept {chan addr port} { ;# Make a proc to accept connections
>>puts "$addr:$port says [gets $chan]" ;# Receive a string
>>puts $chan goodbye   ;# Send a string
>>close $chan  ;# Close the socket (automatically 
>> flushes)
>> }   ;#
>> socket -server accept 12345 ;# Create a server socket)"
>> .Tcl(cmd)
>> .Tcl("vwait myvar")
>> 
>> It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of 
>> course, in this case, R is blocked and waits for the `myvar` variable on the 
>> Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not 
>> catching all Tcl events.
>> 
>> All the best,
>> 
>> Philippe
>> 
>> ..<°}))><
>>  ) ) ) ) )
>> ( ( ( ( (Prof. Philippe Grosjean
>>  ) ) ) ) )
>> ( ( ( ( (Numerical Ecology
>>  ) ) ) ) )   Mons University, Belgium
>> ( ( ( ( (
>> ..
>> 
>>> Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel  a 
>>> écrit :
>>> 
>>> В Tue, 20 Feb 2024 12:27:35 +0100
>>> "webmail.gandi.net"  пишет:
>>> 
 When R process #1 is R 4.2.3, it works as expected (whatever version
 of R #2). When R process #1 is R 4.3.2, nothing is sent or received
 through the socket apparently, but no error is issued and process #2
 seems to be able to connect to the socket.
>>> The difference is related to the change in
>>> src/library/tcltk/src/tcltk_unix.c.
>>> 
>>> In R-4.2.1, the function static void TclSpinLoop(void *data) says:
>>> 
>>>int max_ev = 100;
>>>/* Tcl_ServiceAll is not enough here, for reasons that escape me */
>>>while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--;
>>> 
>>> In R-devel, the function instead says:
>>> 
>>>int i = R_TCL_SPIN_MAX;  
>>>while (i-- && Tcl_ServiceAll())
>>>;
>>> 
>>> Manually calling Tcl_DoOneEvent(0) from the debugger at this point
>>> makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to
>>> be still not enough. I'll try reading Tcl documentation to investigate
>>> this further.
>>> 
>>> -- 
>>> Best regards,
>>> Ivan
>>> 
>>> __
>>> 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
> 
> __
> 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] Tcl socket server (tcltk) does not work any more on R 4.3.2

[Tomas Kalibera]

On 2/21/24 08:01, webmail.gandi.net wrote:

Thank you, Ivan for this investigation. I inspected the R changes file 
(https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing 
about this. I should inspect the sources too!

It could possibly break other Tcl/Tk related stuff. The doc about 
Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when Tcl 
is used from an external program, Tcl_ServiceAll should be used in its event 
loop instead of Tcl_DoOneEvent (and the change in the latest R versions goes in 
that direction). But in the other hand, it is indicated that Tcl_ServiceAll 
does not always handle all Tcl events and extra Tcl_DoOneEvent should be called 
in this case. I think we spotted one case where Tcl_ServiceAll is not doing its 
job correctly. There may be others.

Since the {tcltk} package was working fine with  "while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) 
max_ev—;", unless there is a clear performance enhancement with "while (i-- && 
Tcl_ServiceAll())", it would perhaps be wise to revert this back.


Yes, for now I've done that in R-devel. The Tcl documentation is really 
hard to follow, but debugging reveals that Tcl_ServiceAll() doesn't 
queue new events, as also Ivan reports.


Tomas



Indeed, when I use this on the server side with R 4.3.2:

library(tcltk)
cmd <- r"(
  proc accept {chan addr port} { ;# Make a proc to accept connections
puts "$addr:$port says [gets $chan]" ;# Receive a string
puts $chan goodbye   ;# Send a string
close $chan  ;# Close the socket (automatically 
flushes)
}   ;#
socket -server accept 12345 ;# Create a server socket)"
.Tcl(cmd)
.Tcl("vwait myvar")

It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of 
course, in this case, R is blocked and waits for the `myvar` variable on the 
Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not catching 
all Tcl events.

All the best,

Philippe

..<°}))><
  ) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (Numerical Ecology
  ) ) ) ) )   Mons University, Belgium
( ( ( ( (
..


Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel  a 
écrit :

В Tue, 20 Feb 2024 12:27:35 +0100
"webmail.gandi.net"  пишет:


When R process #1 is R 4.2.3, it works as expected (whatever version
of R #2). When R process #1 is R 4.3.2, nothing is sent or received
through the socket apparently, but no error is issued and process #2
seems to be able to connect to the socket.

The difference is related to the change in
src/library/tcltk/src/tcltk_unix.c.

In R-4.2.1, the function static void TclSpinLoop(void *data) says:

int max_ev = 100;
/* Tcl_ServiceAll is not enough here, for reasons that escape me */
while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--;

In R-devel, the function instead says:

int i = R_TCL_SPIN_MAX; 
while (i-- && Tcl_ServiceAll())
;

Manually calling Tcl_DoOneEvent(0) from the debugger at this point
makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to
be still not enough. I'll try reading Tcl documentation to investigate
this further.

--
Best regards,
Ivan

__
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


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

Re: [Rd] Tcl socket server (tcltk) does not work any more on R 4.3.2

[peter dalgaard]

I don't think we're going to fix this before 4.3.3. Given that it has gone 
unnoticed since June 2022 (yes '22) and that tampering in this area has a 
history of popping up complications in other areas, I think we should leave it 
alone until 4.4.0. 

(I see that Ivan and Tomas has been on the issue since I started writing, but 
the above probably still holds true.)

- Peter D.

> On 21 Feb 2024, at 08:01 , webmail.gandi.net  wrote:
> 
> Thank you, Ivan for this investigation. I inspected the R changes file 
> (https://cran.r-project.org/doc/manuals/r-devel/NEWS.html) and found nothing 
> about this. I should inspect the sources too!
> 
> It could possibly break other Tcl/Tk related stuff. The doc about 
> Tcl_ServiceAll and Tcl_DoOneEvent is confusing. On one hand, it says when Tcl 
> is used from an external program, Tcl_ServiceAll should be used in its event 
> loop instead of Tcl_DoOneEvent (and the change in the latest R versions goes 
> in that direction). But in the other hand, it is indicated that 
> Tcl_ServiceAll does not always handle all Tcl events and extra Tcl_DoOneEvent 
> should be called in this case. I think we spotted one case where 
> Tcl_ServiceAll is not doing its job correctly. There may be others.
> 
> Since the {tcltk} package was working fine with  "while 
> (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is a clear 
> performance enhancement with "while (i-- && Tcl_ServiceAll())", it would 
> perhaps be wise to revert this back.
> 
> Indeed, when I use this on the server side with R 4.3.2:
> 
> library(tcltk)
> cmd <- r"(
> proc accept {chan addr port} { ;# Make a proc to accept connections
>   puts "$addr:$port says [gets $chan]" ;# Receive a string
>   puts $chan goodbye   ;# Send a string
>   close $chan  ;# Close the socket (automatically 
> flushes)
> }   ;#
> socket -server accept 12345 ;# Create a server socket)"
> .Tcl(cmd)
> .Tcl("vwait myvar")
> 
> It works again as expected. And vwait is known to call Tcl_DoOneEvent. Of 
> course, in this case, R is blocked and waits for the `myvar` variable on the 
> Tcl side. Anyway, the problem seems to be really in Tcl_ServiceAll not 
> catching all Tcl events.
> 
> All the best,
> 
> Philippe
> 
> ..<°}))><
> ) ) ) ) )
> ( ( ( ( (Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( (Numerical Ecology
> ) ) ) ) )   Mons University, Belgium
> ( ( ( ( (
> ..
> 
>> Le 20 févr. 2024 à 17:13, Ivan Krylov via R-devel  a 
>> écrit :
>> 
>> В Tue, 20 Feb 2024 12:27:35 +0100
>> "webmail.gandi.net"  пишет:
>> 
>>> When R process #1 is R 4.2.3, it works as expected (whatever version
>>> of R #2). When R process #1 is R 4.3.2, nothing is sent or received
>>> through the socket apparently, but no error is issued and process #2
>>> seems to be able to connect to the socket.
>> 
>> The difference is related to the change in
>> src/library/tcltk/src/tcltk_unix.c.
>> 
>> In R-4.2.1, the function static void TclSpinLoop(void *data) says:
>> 
>>   int max_ev = 100;
>>   /* Tcl_ServiceAll is not enough here, for reasons that escape me */
>>   while (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev--;
>> 
>> In R-devel, the function instead says:
>> 
>>   int i = R_TCL_SPIN_MAX;
>>   while (i-- && Tcl_ServiceAll())
>>   ;
>> 
>> Manually calling Tcl_DoOneEvent(0) from the debugger at this point
>> makes the Tcl code respond to the connection. Tcl_ServiceAll() seems to
>> be still not enough. I'll try reading Tcl documentation to investigate
>> this further.
>> 
>> -- 
>> Best regards,
>> Ivan
>> 
>> __
>> 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

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

[Bioc-devel] Nominations for Bioconductor Awards 2024

[Kern, Lori via Bioc-devel]

Bioconductor is excited to announce an opportunity to recognize those making 
significant outstanding contributions to the Bioconductor community. The 
Bioconductor project is announcing the call for Bioconductor Awards, honoring 
various forms of contributions to the project. Four awardees will be selected, 
each having contributed to the project in an outstanding way based on one or 
more of selection criteria. More information and details can be found on the 
BiocAwards Website:  https://bioconductor.org/about/awards/   Please fill out 
the following form to nominate someone:  https://forms.gle/PBsJQPqBwVuA95xD9
The deadline for nominations is May 15, 2024.

Thank you
On behalf of the BiocAwards Committee



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Re: [Rd] Tcl socket server (tcltk) does not work any more on R 4.3.2

[Ivan Krylov via R-devel]

В Wed, 21 Feb 2024 08:01:16 +0100
"webmail.gandi.net"  пишет:

> Since the {tcltk} package was working fine with  "while
> (Tcl_DoOneEvent(TCL_DONT_WAIT) && max_ev) max_ev—;", unless there is
> a clear performance enhancement with "while (i-- &&
> Tcl_ServiceAll())", it would perhaps be wise to revert this back.

I forgot to mention the comment in the new version of the function
explaining the switch:

>> [Tcl_DoOneEvent(TCL_DONT_WAIT)] <...> causes infinite recursion with
>> R handlers that have a re-entrancy guard, when TclSpinLoop is
>> invoked from such a handler (seen with Rhttp server)

The difference between Tcl_ServiceAll() and Tcl_DoOneEvent() is that
the latter calls Tcl_WaitForEvent(). The comments say that it is called
for the side effect of queuing the events detected by select(). The
function can indeed be observed to access the fileHandlers via the
thread-specific data pointer, which contain the file descriptors and
the instructions saying what to do with them.

Without Tcl_WaitForEvent, the only event sources known to Tcl are
RTcl_{setup,check}Proc (which only checks file descriptors owned by R),
Display{Setup,Check}Proc (which seems to be owned by Tk), and
Timer{Setup,Check}Proc (for which there doesn't seem to be any timers
by default).

As far as I understand the problem, while the function
worker_input_handler() from src/modules/internet/Rhttpd.c is running,
TclHandler() might be invoked, causing Tcl_DoOneEvent() to call
RTcl_checkProc() and therefore trying to run worker_input_handler()
again. The Rhttpd handler prevents this and doesn't clear the
condition, which causes the event loop to keep calling it. Is that
correct? Are there easy ways to reproduce the problem?

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Conversion failure in 'mbcsToSbcs'

[Ivan Krylov]

В Wed, 21 Feb 2024 12:29:02 +
Package Maintainer  пишет:

> Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
>  chunk 58 (label = plotCBText)

In order to use the non-standard graphics device, the chunk must
set the option fig=TRUE. Otherwise, when something calls
graphics::strwidth('Lubomír Kubáček', "inches"), R notices that no
graphics device is active and creates a default one, which happens to
be pdf() and has all these problems. With fig=TRUE, Sweave will
initialise the cairo_pdf() device first, and then graphics::strwidth()
will use the existing device, avoiding the error.

-- 
Best regards,
Ivan

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

Re: [R-pkg-devel] Conversion failure in 'mbcsToSbcs'

[Package Maintainer]

Hello:

Thank you again for your help.

I resubmitted the package (after it passed R CMD check) and it seems
there is still an ERROR on the windows builder as shown here:
https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240221_121754/Debian/00check.log

Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
 chunk 58 (label = plotCBText)
Error in graphics::strwidth(pMPDF$label, "inches") :
  conversion failure on 'Lubomír  Kubáček' in 'mbcsToSbcs': for č (U+010D)

My latest vignette file can be found on the package github:

https://github.com/lindsayrutter/ggenealogy/blob/master/vignettes/ggenealogy.Rnw

The recommended cairo_pdf() syntax was used on lines 47-54:

<>=
my.Swd <- function(name, width, height, ...)
 grDevices::cairo_pdf(
  filename = paste(name, "pdf", sep = "."),
  width = width, height = height
 )
@
\SweaveOpts{grdevice=my.Swd,pdf=FALSE}

I am a bit unsure how to remove this persisting ERROR; is there
anything else you might recommend I look into?

Thank you again.

LAR

On Mon, Feb 19, 2024 at 5:48 PM Package Maintainer
 wrote:
>
> Dear Duncan:
>
> Thank you for the feedback about that. I have removed the unrecognized
> file and resubmitted the package. Thanks again.
>
> Kind regards,
> LAR
>
>
> On Mon, Feb 19, 2024 at 2:20 PM Duncan Murdoch  
> wrote:
> >
> > Removing (or moving to inst) the unrecognized file should be sufficient.
> >
> > Duncan Murdoch
> >
> > On 19/02/2024 7:27 a.m., Package Maintainer wrote:
> > > Hello all:
> > >
> > > Thank you both for your advice.
> > >
> > > I attempted to upload the latest version to CRAN, and again received
> > > the notification that the package did not pass.
> > >
> > > It seems there are no warnings or errors (only 2 notes) on windows
> > > (https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240219_122904/Windows/00check.log)
> > > and debian 
> > > (https://win-builder.r-project.org/incoming_pretest/ggenealogy_1.0.3_20240219_122904/Debian/00check.log).
> > >
> > > One of the notes is simply stating that the package has been archived
> > > (which occurred even when I contacted folks before the deadline). The
> > > other note I can fix easily (an unrecognized file type in the main
> > > directory).
> > >
> > > The only error delineated to me appears to be from a submission back
> > > in November 2023
> > > (https://cran-archive.r-project.org/web/checks/2023/2023-11-14_check_results_ggenealogy.html).
> > >
> > > Is there anything particular I should do? >
> > > Thank you.
> > >
> > > Kind regards,
> > > LAR
> > >
> > > On Sat, Feb 17, 2024 at 1:18 PM Duncan Murdoch  
> > > wrote:
> > >>
> > >> At line 66 of your document, you have this chunk:
> > >>
> > >> <>=
> > >> rm(list=ls())
> > >> @
> > >>
> > >> That removed the device.  You need to put its definition after that.
> > >> (It might also need to come earlier if you're doing plotting before
> > >> this, and again even later if you remove it again.)
> > >>
> > >> By the way, I'd recommend using knitr for Rnw documents instead of
> > >> Sweave.  It will require a few changes, but in general it's more
> > >> flexible and works a bit better.
> > >>
> > >> Duncan Murdoch
> > >>
> > >>
> > >>
> > >> On 17/02/2024 7:51 a.m., Package Maintainer wrote:
> > >>> Dear Ivan:
> > >>>
> > >>> Thank you for your help again.
> > >>>
> > >>> Thanks for your suggestion to use cairo_pdf() instead of pdf() to
> > >>> allow for the multi-lingual plots.
> > >>>
> > >>> I incorporated your advice and added the the code you suggested:
> > >>>
> > >>> <>=
> > >>> my.Swd <- function(name, width, height, ...)
> > >>>grDevices::cairo_pdf(
> > >>> filename = paste(name, "pdf", sep = "."),
> > >>> width = width, height = height
> > >>>)
> > >>> @
> > >>> \SweaveOpts{grdevice=my.Swd,pdf=FALSE}
> > >>>
> > >>> as shown in lines 49-56 in my new vignette file here
> > >>> (https://github.com/lindsayrutter/ggenealogy/blob/master/vignettes/ggenealogy.Rnw).
> > >>>
> > >>> Upon attempting to build (R CMD build ggenealogy), I received the ERROR:
> > >>>
> > >>> Error: processing vignette 'ggenealogy.Rnw' failed with diagnostics:
> > >>> object 'my.Swd' not found
> > >>> --- failed re-building ‘ggenealogy.Rnw’
> > >>>
> > >>> I tried replacing the code you suggested to various locations and
> > >>> separating the \SweaveOpts line to be located at separate locations.
> > >>> However, I received the same ERROR each time.
> > >>>
> > >>> Do you have any suggestions or ideas on how to resolve this error?
> > >>>
> > >>> I again thank you for your help with this issue.
> > >>>
> > >>> Kind regards,
> > >>> LAR
> > >>>
> > >>>
> > >>> On Thu, Feb 15, 2024 at 3:17 PM Ivan Krylov  
> > >>> wrote:
> > 
> >  В Mon, 12 Feb 2024 16:01:27 +
> >  Package Maintainer  пишет:
> > 
> > > Unfortunately, I received a reply from the CRAN submission team
> > > stating that my vignette file is still obtaining the "mbcsToSbcs"
> > > ERROR as is shown 

Re: [Rd] Bug in comparison of language objects?

[Martin Maechler]

> Duncan Murdoch 
> on Tue, 20 Feb 2024 08:47:30 -0500 writes:

> On 20/02/2024 8:03 a.m., Duncan Murdoch wrote:
>> I noticed the following odd behaviour today:
>> 
>> exprs <- expression( mean(a), mean(b), { a }, { b } )
>> 
>> exprs[[1]] == exprs[[2]] #> [1] FALSE
>> 
>> exprs[[3]] == exprs[[4]] #> [1] TRUE
>> 
>> Does it make sense to anyone that the argument passed to
>> `mean` matters, but the expression contained in braces
>> doesn't?

> I have done some debugging, and found the cause: for the
> comparison of language objects, R deparses them to strings
> using C function deparse1(), and looks at only the first
> line.  "mean(a)" deparses as is, but "{ a }" deparses to 3
> lines

> { a }

> and the first line is the same as for "{ b }", so they
> compare equal.

> I think it would make more sense to deparse them to one
> long string, and compare those, i.e. to replace deparse1()
> with deparse1line() (which may have been the intention).

> Duncan Murdoch

I agree ... (and more do).
Thank you for  adding it as formal report to R's bugzilla,
https://bugs.r-project.org/show_bug.cgi?id=18676

Unfortunately, it triggers something in the (byte) compiler test
suite, and (also/hence) will probably be too late for R 4.3.3.

Martin

Martin Maechler

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