Re: [Rd] Regenerate news feeds?

[Simon Urbanek]

Tim,

thanks. I have updated R to the latest R-devel on the machine in the hope that 
is may help, but I suspect it will only affect new entries as they are 
generated progressively each day.

Cheers,
Simon


> On Nov 18, 2023, at 11:38 AM, Tim Taylor  
> wrote:
> 
> The news feeds (e.g. 
> https://developer.r-project.org/blosxom.cgi/R-devel/NEWS) have some stray 
> "\abbr" floating around. Do they need generating with a more recent version 
> of R-devel?
> 
> I've run tools::Rd2txt on https://svn.r-project.org/R/trunk/doc/NEWS.Rd and 
> r85550 does seem to remove these abberations (compared to the same function 
> calling on an unpatched 4.3.2 where they remain).
> 
> Tim
> 

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

Re: [Bioc-devel] Workflow package build all OK but no vignette and red Package propagation status LED

[Hervé Pagès]

Hi Jim,

On 11/17/23 06:22, James Perkins wrote:
> Thanks I didn't know about the mouseover hint! It appears that this 
> package (miRBaseConverter) is failing the check on linux:
>
> https://bioconductor.org/checkResults/3.18/bioc-LATEST/miRBaseConverter/
>
> Leading to the red light ExpHunterSuite on the linux build only:
>
> https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/ 
>
>
> However, what I'm not sure about - is this unavailable dependency the 
> reason why the landing page for ExpHunterSuite does not show the 
> vignette or source code?
>
> https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html
>
Yes. The vignettes displayed on the package landing pages are generated 
from what's found in the _published_ source tarball. Since no source 
tarball for ExpHunterSuite ever made it to the BioC 3.18 repositories, 
the landing page that we produce is missing a few things (it's a 
degraded version of the standard landing page).

Note that miRBaseConverter has been failing on Linux for more than 6 
months, for not declaring BiocStyle in its Suggests field, and despite 
numerous reminders (emails sent by core team members in addition to the 
weekly automatic BBS notifications). Maybe you want to try and ping the 
miRBaseConverter maintainer by opening an issue at 
https://github.com/taoshengxu/miRBaseConverter ? Maybe you'll have more 
luck.

Otherwise, we will soon deprecate miRBaseConverter in BioC 3.19. 
Unfortunately this means that you'll need to modify the ExpHunterSuite 
workflow to no longer rely on it.

Best,

H.


> Or could it be another factor?
>
> Jim
>
> On 2023-11-13 12:08, Martin Grigorov wrote:
>> Hi,
>>
>> If you hover over the red LED you will see the following hint: NO,
>> package depends on 'miRBaseConverter' which is not available"
>>
>> Regards,
>> Martin
>>
>> On Mon, Nov 13, 2023 at 11:31 AM James Perkins 
>> wrote:
>>
>>> Hi,
>>>
>>> I am the maintainer of the Workflow package ExpHunterSuite.
>>>
>>> In the build report for the release branch, 3.18, my build and
>>> install
>>> status are green-OK.
>>>
>>> However, I have a red LED for Package Propagation. How can I tell
>>> what's
>>> gone wrong, and how could I fix it?
>>>
>>>
>> https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/ 
>>
>>>
>>> I've had a look through the documentation and the nearest I've found
>>>
>>> was: "propagation is still determined by the results of the nightly
>>> builds." - but I cannot find/workout the relevant section in the
>>> output
>>> of the nightly build report that is related to propagation status.
>>>
>>> The landing page of the package is not showing the documentation
>>> (vignette etc.), or letting me download the package source.
>>>
>>>
>> https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html 
>>
>>>
>>> I suspect this is related, because the devel version of the package
>>> IS
>>> showing blue propagation status, and IS showing the
>>> documentation/package source etc.
>>>
>>>
>> https://bioconductor.org/packages/3.19/workflows/html/ExpHunterSuite.html 
>>
>>>
>>> Cheers!
>>>
>>> Jim
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> ___
> 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

[Rd] Regenerate news feeds?

[Tim Taylor]

The news feeds (e.g. 
https://developer.r-project.org/blosxom.cgi/R-devel/NEWS) have some 
stray "\abbr" floating around. Do they need generating with a more 
recent version of R-devel?


I've run tools::Rd2txt on https://svn.r-project.org/R/trunk/doc/NEWS.Rd 
and r85550 does seem to remove these abberations (compared to the same 
function calling on an unpatched 4.3.2 where they remain).


Tim

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

Hello!

В Fri, 17 Nov 2023 14:16:27 +
Package Maintainer  пишет:

> 2) set_null_device("cairo") to the vignettes/ggenealogy.Rnw file (this
> gives me a "could not find function "set_null_device"" ERROR)

I don't think this function from the cowplot package would have helped.
You are compiling a LaTeX vignette, so you need to produce a PDF plot
to include in the rendered PDF vignette.

> 1) pdf.options(encoding='ISOLatin2.enc') to the
> vignettes/ggenealogy.Rnw file

Something like this should help. Here's how I can reproduce the problem
on latest R-devel:

Sys.setenv('_R_CHECK_MBCS_CONVERSION_FAILURE_' = 'TRUE')
pdf()
graphics::strwidth('Lubomír Kubáček', "inches")
# Error in graphics::strwidth("Lubomír Kubáček", "inches") :
#   conversion failure on 'Lubomír Kubáček' in 'mbcsToSbcs': for í
#   (U+00ED)

Notably, the error is absent if I either call
pdf.options(encoding='ISOLatin2.enc') before pdf() or replace pdf()
with the better-Unicode-equipped cairo_pdf().

As a workaround, you could use the latter device in your vignette by
following section "Custom Graphics Devices" of help(RweaveLatex) (or
section 4.1.5 "Graphics devices" of the Sweave vignette):

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

With this in the document, the following chunk doesn't crash
_R_CHECK_MBCS_CONVERSION_FAILURE_=TRUE R-devel CMD Sweave:

<>=
# NB: fig=TRUE must be set, otherwise R calls pdf() with default options
graphics::strwidth('Lubomír Kubáček', "inches")
@

So why doesn't it help to call pdf.options() in a Sweave chunk? My
guess is that's too late for Sweave to pick it up by the time it's
weaving a vignette, but RweaveLatex presents an alternative way of
setting the option:

\SweaveOpts{pdf.encoding = ISOLatin2.enc}

With this in the vignette, my previous example also avoids the crash.

Good luck!

-- 
Best regards,
Ivan

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

Re: [Rd] system()/system2() using short paths of commands on Windows?

[Yihui Xie]

The problem in TeX Live has just been fixed. Now it will expand short
names: https://tug.org/pipermail/tex-live/2023-November/049706.html
Therefore please feel free to ignore my original request. Thank you!

Regards,
Yihui
--
https://yihui.org


On Thu, Nov 16, 2023 at 8:28 AM Tomas Kalibera  wrote:
>
>
> On 10/31/23 10:05, Duncan Murdoch wrote:
> > On 31/10/2023 4:32 a.m., Tomas Kalibera wrote:
> >>
> >> On 10/30/23 19:07, Yihui Xie wrote:
> >>> Sure. I'm not sure if it's possible to make it easier to reproduce,
> >>> but for now the example would require installing TinyTeX (via
> >>> tinytex::install_tinytex(), which can be later uninstalled cleanly via
> >>> tinytex::uninstall_tinytex() after you finish the investigation). Then
> >>> run:
> >>>
> >>>system2('fmtutil-sys', '--all')
> >>># or tinytex:::fmtutil() if fmtutil-sys.exe is not on PATH
> >>>
> >>> and TeX Live would throw an error like this:
> >>>
> >>> ...\username\AppData\Roaming\TinyTeX\bin\windows\runscript.tlu:864: no
> >>> appropriate script or program found: fmtuti~1
> >>>
> >>> The command "fmtutil-sys" is longer than 8 characters and hence
> >>> shortened to "fmtutil~1". Yes, in principle, TeX Live should work with
> >>> short path names, but it doesn't at the moment. I haven't figured out
> >>> if it was a recent breakage in TeX Live or not (I've tried to contact
> >>> TeX Live developers).
> >>>
> >>> BTW, shell('fmtutil-sys --all') works fine.
> >>
> >> I can reproduce the problem, also separately from R. It is not an R
> >> problem
> >>
> >> ./fmtutil-sys.exe --version
> >> works
> >>
> >> ./fmtuti~1 --version
> >> doesn't work
> >>
> >> The problem is in runscript.tlu, when it looks at "progname", it parses
> >> it assuming it is the full name, looking for "-sys" suffix, which won't
> >> be in the short name:
> >>
> >> progname, substcount = string.gsub(progname, '%-sys$', '')
> >> local sysprog = (substcount > 0) -- true if there was a -sys suffix
> >> removed
> >>
> >> and it does further processing using the program name.
> >>
> >> This has to be fixed on the luatex end, it must be able to work with
> >> short paths (e.g. expand it appropriately). You could probably work
> >> around the installation before it gets fixed, e.g. by creating another
> >> wrapper which would expand to long names, delete the short name, patch
> >> the script, etc. After all, if it works via a shell, then probably the
> >> shell is expanding to the long names and you have a work-around (I don't
> >> know how reliable).
> >>
> >> Adding an option to R's system*() functions to use only long names
> >> doesn't make sense.
> >
> > On the other hand, not modifying the executable name would make a lot
> > of sense, wouldn't it?  I'm pretty sure all supported versions of
> > Windows can handle long filenames.
>
> There could be an option to pass the "module" name directly, which would
> end up as the first argument of CreateProcess, so avoid the search-path
> lookup and the complete path expansion. That would make sense, but I am
> not persuaded it is needed. I don't think the luatex wrapper bug is a
> strong enough case to complicate the code and API (which is already
> rather complicated) any further. It would not be "just" a new option,
> but also dissecting the module name from the command (when not using a
> shell).
>
> While thinking about this and reading the related code I found a bug in
> handling paths with spaces when short paths are not available, fixed now.
>
> Tomas
>
> >
> > Duncan Murdoch
> >

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

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

[Package Maintainer]

Hello:

About three weeks ago, I received a message that a CRAN package I maintain
(ggenealogy) had issues with "Unicode chars not available to pdf()".

As shown here
,
it seems ERRORs occur when building the vignette, such as:

1) conversion failure on 'Lubomír Kubáček' in 'mbcsToSbcs': for č (U+010D)
2) conversion failure on 'Anders Ågren' in 'mbcsToSbcs': for Å (U+00C5)

I have attempted to add lines such as:

1) pdf.options(encoding='ISOLatin2.enc') to the vignettes/ggenealogy.Rnw
file
2) set_null_device("cairo") to the vignettes/ggenealogy.Rnw file (this
gives me a "could not find function "set_null_device"" ERROR)

I have been a bit stuck on how to resolve these new issues. A few days ago,
I noticed my package was removed from CRAN before the stated deadline AoE
(Anywhere on Earth), and so I decided to upload all changes I had made up
until that point into a new ggenealogy_1.0.2.tar.gz file to the CRAN
submission website. However, it seems the problem remain, and so I'm now
reaching out to the list-serve to see if this may help me resolve the
issues in a timely manner.

Thank you for your patience and guidance.

Kind regards,
LAR

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Package submission fail

[Christiaan Pieterse]

Hi all, thank you for your feedback and help! I apologise for the big
attachment.

I have made the changes you suggested but am still encountering some of the
same notes, If you do not mind to assist me again I would greatly
appreciate!

I reduced the example file to a 3 KB file, hoping that it would reduce my
runtime, but I still received this note:
* checking examples ... [26s] NOTE
Examples with CPU (user + system) or elapsed time > 5s
  user system elapsed
IOPS 15.23   2.89   22.41
Is there any other way to reduce this time? I have gone through my code and
can't find any areas to change that will help this.

Then the 2nd and 3rd notes relate to the example and its outputs. I do not
know how to fix this.
* checking for non-standard things in the check directory ... NOTE
Found the following files/directories:
  'Combined_Results.csv' 'Combined_Results.xlsx'
* checking for detritus in the temp directory ... NOTE
Found the following files/directories:
  'lastMiKTeXException'

I have changed my code to include the tempdir() as suggested before but it
doesn't seem to work. I then tried to use the \donttest{} method also
suggested before. I don't know if I am doing this wrong.
Here is my updated example code:

#' @examples
#' \donttest{
#'
#' # Set the working directory to a temporary directory
#' setwd(tempdir())
#'
#' # Load the example data
#' ExampleTradeData <- read.csv(system.file("extdata",
"ExampleTradeData.csv", package = "iopspackage"))
#'
#'
#' # Then use it in your function
#' IOPS(
#'   CountryCode = 710,
#'   tradeData = ExampleTradeData,
#'   ComplexMethod = "reflections",
#'   iterCompl = 5,
#'   GVCMapping = NULL,
#'   tradedigit = 6
#' )
#'
#' # Clean up the temporary directory
#' unlink(temp_dir, recursive = TRUE)
#' }
#'

Any assistance would be greatly appreciated
Christiaan

On Mon, 13 Nov 2023 at 15:50, Dirk Eddelbuettel  wrote:

>
> On 13 November 2023 at 16:46, Ivan Krylov wrote:
> | Hello Christiaan and welcome to R-package-devel!
>
> Seconded but PLEASE do not send large attachments to the list and all its
> subscriber. Point us to your code repository, you will like get a kind
> response from a volunteer or two peeking at it.
>
> Dirk
>
> --
> dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Workflow package build all OK but no vignette and red Package propagation status LED

[James Perkins]

Thanks I didn't know about the mouseover hint! It appears that this 
package (miRBaseConverter) is failing the check on linux:


https://bioconductor.org/checkResults/3.18/bioc-LATEST/miRBaseConverter/

Leading to the red light ExpHunterSuite on the linux build only:

https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/

However, what I'm not sure about - is this unavailable dependency the 
reason why the landing page for ExpHunterSuite does not show the 
vignette or source code?


https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html

Or could it be another factor?

Jim

On 2023-11-13 12:08, Martin Grigorov wrote:

Hi,

If you hover over the red LED you will see the following hint: NO,
package depends on 'miRBaseConverter' which is not available"

Regards,
Martin

On Mon, Nov 13, 2023 at 11:31 AM James Perkins 
wrote:


Hi,

I am the maintainer of the Workflow package ExpHunterSuite.

In the build report for the release branch, 3.18, my build and
install
status are green-OK.

However, I have a red LED for Package Propagation. How can I tell
what's
gone wrong, and how could I fix it?



https://bioconductor.org/checkResults/3.18/workflows-LATEST/ExpHunterSuite/


I've had a look through the documentation and the nearest I've found

was: "propagation is still determined by the results of the nightly
builds." - but I cannot find/workout the relevant section in the
output
of the nightly build report that is related to propagation status.

The landing page of the package is not showing the documentation
(vignette etc.), or letting me download the package source.



https://bioconductor.org/packages/3.18/workflows/html/ExpHunterSuite.html


I suspect this is related, because the devel version of the package
IS
showing blue propagation status, and IS showing the
documentation/package source etc.



https://bioconductor.org/packages/3.19/workflows/html/ExpHunterSuite.html


Cheers!

Jim

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


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

Re: [R-pkg-devel] Can -mmacosx-version-min be raised to 10.15 ?

[Dirk Eddelbuettel]

Simon,

One more thing: An alert reader pointed out to me that macOS-oldrel has

 r-oldrel-macos-x86_64  r-oldrelmacOS   x86_64  macOS 10.13.6 (17G11023)

in the table at https://cran.r-project.org/web/checks/check_flavors.html. So
this seems to mesh with what the R-on-macOS FAQ says, and switching to 11.0
would appear to at least loose r-oldrel-macos-x86_64 until April, no?

Best,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Package submission fail

[Ivan Krylov]

В Fri, 17 Nov 2023 12:19:21 +0200
Christiaan Pieterse  пишет:

> #' # Set the working directory to a temporary directory
> #' setwd(tempdir())

> #' # Clean up the temporary directory
> #' unlink(temp_dir, recursive = TRUE)

This code looks like it shouldn't be working as written. I don't see
the variable temp_dir being defined anywhere, so it should have failed
with Error: object 'temp_dir' not found. Have you run roxygenise() in
order to generate the man/*.Rd files (which is what R cares about)?

It's best to avoid changing the global state of the application,
including the current directory. When you have to setwd(), do it the
following way:

oldwd. <- setwd(...)
# do the thing
setwd(oldwd.)

In my opinion, it's better to provide an argument for your function to
let the user specify the destination file. This would let the user say
IOPS(outfile = 'Combined_Results_2.xlsx') without overwriting the
Combined_Results.xlsx that already exists or even outfile =
file.path(tempdir(), 'whatever.xlsx') to put the file into another
directory. I think you will also need to remove that file at the end of
your example. (Cleaning the whole tempdir(), on the other hand, could
be bad for the user.)

> * checking examples ... [26s] NOTE
> Examples with CPU (user + system) or elapsed time > 5s
>   user system elapsed
> IOPS 15.23   2.89   22.41

22 seconds is much better!

How much time is spent in read.csv(system.file("extdata",
"ExampleTradeData.csv", package = "iopspackage"))? Can you resave it
under data/*.rda, load it using data() and save some time there?

If you cannot squeeze your data even further, it may help to profile
the example(IOPS) run [1] and try to find faster alternatives for the
parts of the code that take the most time. It's not exactly trivial
(make sure to read both WRE 3.2 and help(Rprof)), but it should be
possible to improve your time.

-- 
Best regards,
Ivan

[1]
https://cran.r-project.org/doc/manuals/R-exts.html#Profiling-R-code-for-speed

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

[Bioc-devel] News: Bioconductor's Transition Away from Twitter/X

[Maria . Doyle]

Dear Bioconductor Community,

We are transitioning away from Twitter/X in favour of platforms more aligned 
with our Code of Conduct. For details, see our blog post: 
https://blog.bioconductor.org/posts/2023-11-17-twitter-exit/

Maria Doyle, PhD
Bioconductor Community Manager

School of Medicine,
University of Limerick, Limerick, V94 T9PX
Ireland
Email: maria.do...@ul.ie
Phone (office): +353 61 234 768
[I work flexible hours across several time zones. I don't expect you to read or 
respond to my emails outside of your normal working hours]


[[alternative HTML version deleted]]

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