Re: [R-pkg-devel] Warning when the --as-cran flag is used, not otherwise.

[David Winsemius]

Speaking as a potential user of such a package, I wonder if that 
information could be put in a help page for the entire package? I've 
seen several packages that do such a "global" overview. I realize there 
might be a Suggests: entry in the DESCRIPTION file but not everyone 
knows how to find it and even those who do might first try for a help 
page if it was in the Index.


On 1/16/24 22:39, Rolf Turner wrote:

On Tue, 16 Jan 2024 23:53:15 +0100
Sebastian Meyer  wrote:


There is a note on your help page that says

These data are **not** immediately available in the `eglhmm` package.

which seems to be in line with the check warning.

OK.  Thanks.  Now that you have pointed this out, it's all too obvious.
The user is invited to install the monoCyteSim package (from a specified
github repository).  After the user has done so, then the data sets
bivarSim and ccSim are available in the usual way.

When I ran R CMD check without the --as-cran flag, there was no problem
because I had already installed the monoCyteSim package on my local
computer.  *With* that flag, R CMD check carries on as if it were
looking at the eghlmm package in the context of running on a CRAN
server.  This server would *not* have the monoCyteSim package
installed, whence it would not be able to find the data sets bivarSim
and ccCM, whence the warning.  Makes perfect sense now.

It turns out I can make the warning go away by removing the lines

\usage{
 bivarSim
 ccSim
}

They serve no useful purpose and are not required.

Thanks again.

cheers,

Rolf Turner



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

Re: [R-pkg-devel] Package from in imports bioconductor is not compiling on R-devel

[David Winsemius]

This is the package DESCRIPTION after installing the current version from the 
Bioc repo:

> packageDescription("SNPRelate")
Package: SNPRelate
Type: Package
Title: Parallel Computing Toolset for Relatedness and Principal Component 
Analysis
of SNP Data
Version: 1.28.0
Date: 2021-10-19
Depends: R (>= 2.15), gdsfmt (>= 1.8.3)
LinkingTo: gdsfmt
Imports: methods
Suggests: parallel, Matrix, RUnit, knitr, markdown, rmarkdown, MASS, 
BiocGenerics
Enhances: SeqArray (>= 1.12.0)
Authors@R: c(person("Xiuwen", "Zheng", role=c("aut", "cre", "cph"),
email="zhe...@u.washington.edu", 
comment=c(ORCID="-0002-1390-0708")),
person("Stephanie", "Gogarten", role="ctb", email="sdmor...@uw.edu"),
person("Cathy", "Laurie", role="ctb", email="cclau...@uw.edu"),
person("Bruce", "Weir", role=c("ctb", "ths"), email="bsw...@uw.edu",
comment=c(ORCID="-0002-4883-1247")))
Description: Genome-wide association studies (GWAS) are widely used to 
investigate
the genetic basis of diseases and traits, but they pose many
computational challenges. We developed an R package SNPRelate to provide
a binary format for single-nucleotide polymorphism (SNP) data in GWAS
utilizing CoreArray Genomic Data Structure (GDS) data files. The GDS
format offers the efficient operations specifically designed for 
integers
with two bits, since a SNP could occupy only two bits.  SNPRelate is 
also
designed to accelerate two key computations on SNP data using parallel
computing for multi-core symmetric multiprocessing computer
architectures: Principal Component Analysis (PCA) and relatedness
analysis using Identity-By-Descent measures. The SNP GDS format is also
used by the GWASTools package with the support of S4 classes and generic
functions. The extended GDS format is implemented in the SeqArray 
package
to support the storage of single nucleotide variations (SNVs),
insertion/deletion polymorphism (indel) and structural variation calls 
in
whole-genome and whole-exome variant data.
License: GPL-3
VignetteBuilder: knitr
URL: http://github.com/zhengxwen/SNPRelate
BugReports: http://github.com/zhengxwen/SNPRelate/issues
biocViews: Infrastructure, Genetics, StatisticalMethod, PrincipalComponent
git_url: https://git.bioconductor.org/packages/SNPRelate
git_branch: RELEASE_3_14
git_last_commit: 8fcd837
git_last_commit_date: 2021-10-26
Date/Publication: 2021-10-26
NeedsCompilation: yes
Packaged: 2021-10-27 03:33:37 UTC; biocbuild
Author: Xiuwen Zheng [aut, cre, cph] (<https://orcid.org/-0002-1390-0708>),
Stephanie Gogarten [ctb], Cathy Laurie [ctb], Bruce Weir [ctb, ths]
(<https://orcid.org/-0002-4883-1247>)
Maintainer: Xiuwen Zheng 
Built: R 4.1.1; x86_64-apple-darwin17.0; 2021-10-27 17:11:51 UTC; unix

-- File: 
/Library/Frameworks/R.framework/Versions/4.1/Resources/library/SNPRelate/Meta/package.rds
—
David. 

Sent from my iPhone

> On May 10, 2022, at 9:47 PM, David Winsemius  wrote:
> 
> You can download the source from the package archives. It can then be 
> installed from a terminal console and the logs should tell you the problem. 
> 
> — 
> David. 
> 
> Sent from my iPhone
> 
>> On May 10, 2022, at 9:19 PM, Bernd.Gruber  
>> wrote:
>> 
>> Hi,
>> 
>> 
>> I just got an email from Brian Ripley, which informed me that one of my 
>> dependencies in imports (SNPRelate) cannot be installed in R-devel and that 
>> I should check the check pages on CRAN or contact the maintainer.
>> 
>> 
>> 
>> AsS SNPRelate is actually a Bioconductor package (has been removed from CRAN 
>> in 2014) I do not know which check pages I am supposed to check.
>> 
>> 
>> 
>> I definitely will contact the maintainer, but to understand why it is not 
>> compiling is there a way to find out, so I can direct the maintainer to the 
>> problem more efficiently?
>> 
>> 
>> 
>> Thanks, Bernd
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> ==
>> Dr Bernd Gruber  )/_
>>_.--..---"-,--c_
>> Professor Ecological Modelling  \|..'   ._O__)_
>> Tel: (02) 6206 3804 ,=._.+   _ \..--( /
>> Fax: (02) 6201 2328   \\.-''_.-' \ ( \_
>> Institute for Applied Ecology  

Re: [R-pkg-devel] how to address CRAN FAIL on r-devel-windows-x86_64-gcc10-UCRT?

[David Winsemius]

On 4/2/21 1:08 PM, David Winsemius wrote:


On 4/2/21 4:05 AM, Daniel Kelley wrote:
The "oce" package for oceanographic analysis is failing a check on 
the r-devel-windows-x86_64-gcc10-UCRT system (see
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64-gcc10-UCRT/oce-00check.html). 
The problem seems to relate to the checking vignette outputs.


According to 
https://www.r-project.org/nosvn/winutf8/ucrt3/CRAN/checks/gcc10-UCRT/README.txt, 
that test setup is experimental.  Does that mean that I ought to I 
ignore the FAIL status for this machine, perhaps checking it once in 
a while to see if it changes?

Hello Daniel;

I'm not speaking for CRAN. I'm another maintainer whose current status 
page has a FAIL for that platform. But the FAIL notation is due at 
least in part to the fact that apparently the UCRT platform is less 
frequently run on the full CRAN package holdings. The note refers to a 
package that was updated a few days ago. The log file however has two 
other reports of failure relating to compiler warnings.


All the other platforms passed the newer versions. There is no mention 
of the UCRT platform at the CRAN Policies page: 
https://cran.r-project.org/web/packages/policies.html


I'm waiting to see whether the aging fortran code generates warnings 
whenever the UCRT platform gets fired up again.



Follow-up on UCRT package checks for muhaz package. When the version 
that corrected R code errors was eventually run, it now has a status of 
"OK". Apparently the warnings about the Fortran code are not 
sufficiently worrisome. It still have an LTO link but the status page 
doesn't even consider the warnings contained therein to be worthy of 
being called warnings or notes.



--

David Winsemius

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

Re: [R-pkg-devel] how to address CRAN FAIL on r-devel-windows-x86_64-gcc10-UCRT?

[David Winsemius]

On 4/2/21 4:05 AM, Daniel Kelley wrote:

The "oce" package for oceanographic analysis is failing a check on the 
r-devel-windows-x86_64-gcc10-UCRT system (see
https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64-gcc10-UCRT/oce-00check.html).
 The problem seems to relate to the checking vignette outputs.

According to 
https://www.r-project.org/nosvn/winutf8/ucrt3/CRAN/checks/gcc10-UCRT/README.txt,
 that test setup is experimental.  Does that mean that I ought to I ignore the 
FAIL status for this machine, perhaps checking it once in a while to see if it 
changes?

Hello Daniel;

I'm not speaking for CRAN. I'm another maintainer whose current status 
page has a FAIL for that platform. But the FAIL notation is due at least 
in part to the fact that apparently the UCRT platform is less frequently 
run on the full CRAN package holdings. The note refers to a package that 
was updated a few days ago. The log file however has two other reports 
of failure relating to compiler warnings.


All the other platforms passed the newer versions. There is no mention 
of the UCRT platform at the CRAN Policies page: 
https://cran.r-project.org/web/packages/policies.html


I'm waiting to see whether the aging fortran code generates warnings 
whenever the UCRT platform gets fired up again.


--

David Winsemius

maintainer (but neither author or contributor) of "muhaz"



Alternatively, if I am advised to fix the problem, I wonder whether there a way 
for me to run tests with rhub, winbuilder, or something similar?  (I do not 
have access to a windows machine.)

Thanks in advance for any help that can be provided.

Dan Kelley, Dept. Oceanography, Dalhousie University, Canada
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel


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

Re: [R-pkg-devel] MacOS flat namespace

[David Winsemius]

On 5/7/20 7:37 AM, Fabio Corradini Santander wrote:
> Hi,
> Thank you both very much for your help. Summarizing your comments:
> 1. There were no problems when installing the package from CRAN on a macOS
> Catalina with clang11 and R 4.0.0.
> 2. Since I don't use any of the objects directly, it is probably a gdal
> thing due to an improper(?) installation.
>
> OK, but the problem happens on CRAN during the CRAN checks for the OS X and
> macOS system flavors... Does this mean that there might be something wrong
> with CRAN gdal installation for OS X and macOS? (I don't think so, plus how
> can I check that without bothering CRAN maintainers?)
>
>> Make sure you have a proper gdal installation; after that things should
>> work. If you want you could be more defensive about this, and add some
>> logic to your configure script to test if a binary compiled against gdal
>> runs correctly or not, and react accordingly (e.g., if gdal is a strong
>> dependency then you don't continue further into the compilation of your
>> package).
> Although Rodrigo suggestion will work, if I abort the installation I will
> fail the CRAN check, which is the reason I'm asking this question...

You might want to look at the 'sf' package to see how it handles GDAL 
SystemRequirements.

When I was using MacOS a few years ago I would typically need to make 
GDAL available on my system using the KingChaos distribution of the 
GDAL, GEOS, PROJ bundle whenever there was a major change in macOS. It 
provides a proper framework installation.

If the user has chosen (against the Mac fork's maintainer's advice)  to 
install GDAL and friends using homebrew, there may be difficulty during 
the linkage steps trying to find the headers that will not be in the 
expected directory. If they have gone the homebrew route, then I believe 
there are additional steps needed to establish the proper system 
environment symlinks and/or environment variables. You can probably find 
some discussion in the R-sig-mac mailing list archives. I generally use 
the MarkMail search facility. You can try:


https://markmail.org/search/?q=+list%3Aorg.r-project.r-sig-mac+gdal


  You might want to post the question on the R-sig-mac mailing list if 
you remain stuck.

-- 

David.

>
> Thanks once again,
>
> Fabio.
>

[[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] Need help testing for Apple

[David Winsemius]

> On Mar 11, 2020, at 11:39 AM, Neal Fultz  wrote:
> 
> Hello,
> 
> I am working on a package that does terminal graphics for hterm, but iterm2
> should work too; if you have an apple computer with iterm2, could you
> please help test it for me?
> 
> Installation:
> 
>remotes::install_github("nfultz/osc1337")
> 
> Then run this demo:
> 
>demo("barplot", "osc1337")
> 
> Try running it from a shell, and also inside screen and tmux, and let me
> know if you see the barplot in each case. Version numbers might be helpful
> too.
> 
> *** it does not work in rstudio ***

I'm not sure what is supposed to happen. On my device running the R.app I see:

> barplot(1:10, col=1:10)
Hit  to see next plot: 

> osc1337()
/var/folders/68/vh2f8kzn09j8954r6q9100yhgn/T//RtmpC2yMm9/fileefa4178b3c1.png
 
 480 480 
9684 
]1337;File=name=ZmlsZWVmYTQxNzhiM2MxLnBuZw==;width=480;height=480;inline=1:iVBORw0KGgoNSUhEUgAAAeHgCAYAAAB91L6VAAAEGWlDQ1BrQ0dDb2xvclNwYWNlR2VuZXJpY1JHQgAAOI2NVV1oHFUUPrt

#and then a couple of pages of gibberish
#and finally...

detach("package:osc1337")
Warning message:
.onDetach failed in detach() for 'osc1337', details:
  call: dev.off(oldopts$i)
  error: QuartzBitmap_Output - unable to open file '/dev/null' 


In a terminal session I see much the same but with none of the garbage text:

>  demo("barplot", "osc1337")


demo(barplot)
 ~~~

Type to start : 

> library(osc1337)

> barplot(1:10, col=1:10)
Hit  to see next plot: 

> osc1337()
/var/folders/68/vh2f8kzn09j8954r6q9100yhgn/T//Rtmp1oeFuH/file2b9d310dee06.png
 
 480 480 
9684 

> detach("package:osc1337")
Warning message:
.onDetach failed in detach() for 'osc1337', details:
  call: dev.off(oldopts$i)
  error: QuartzBitmap_Output - unable to open file '/dev/null' 


R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.0 (64-bit)


HTH (but I not sure how it would)
-- 
David.

> 
> Thanks much!
> 
> - Neal Fultz
> 
> PS If anyone from rstudio is on the list, would you mind
> explaining RShadowPngGraphicsHandler.cpp and friends, and how it knows when
> to redraw when R returns to the REPL prompt?
> 
> I'd like to do something similar so that drawing plots in the terminal is
> less manual.
> 
> Haven't found much docs on the graphics engine other than a really old
> omegahat project, been trying to read engine.c but I'm slow.
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

Re: [R-pkg-devel] pdflatex is not available

[David Winsemius]

I thought TexLive is the usual place to get pdflatex.

Appears I am not the only one who thinks that.


https://askubuntu.com/questions/1161821/pdflatex-not-found-while-installing-r-software-on-ubuntu-19-04


--

David.

On 12/13/19 4:06 PM, Cathy Lee Gierke wrote:

Does anyone know why I might get this error?

Hmm ... looks like a package

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :

   pdflatex is not available

Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet,  :

*  pdflatex is not available*

*Error in running tools::texi2pdf()*

You may want to clean up by 'rm -Rf
/var/folders/0m/41bxx35j5x9f_tks7zrd7jh0gn/T//Rtmpuv00M5/Rd2pdf8f2a123193cb'

* checking for detritus in the temp directory ... OK

* DONE



There are no clues in the Rdlatex.log
I have attached the ...manual.tex file.  Is there a way to check it for
non-ascii or non-printing characters on a Mac?  I have had that problem
before, but I'm not finding any now.  Maybe I have the wrong command?


find /Users/user/CATkit/CATkit/man | perl -ne 'print if /[^[:ascii:]]/'

find /Users/user/CATkit/CATkit/man/CatCall.rd | perl -ne 'print if
/[^[:ascii:]]/'


Should there be a pdf file somewhere?

Thanks,
Cathy Lee Gierke



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


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

Re: [R-pkg-devel] winbuilder fails for package depending on rJava

[David Winsemius]

On 10/30/19 3:46 AM, Duncan Murdoch wrote:

On 29/10/2019 7:23 p.m., David Winsemius wrote:


On 10/29/19 2:12 PM, Jeff Newmiller wrote:
Once again, you can color me mystified. Are you reading logs not 
referred to in this email thread?


Hi Jeff;

I suppose am reading  else. I ran:

maintainer("rJava")


... and the result was Simon Urbanek's name (which wasn't surprising to
me), and did not match the name of the OP.

So I was (and am) puzzled that  Kevin was using win-builder on rJava.



I think you misread his post.  He was using win-builder on packages 
that depend on rJava.  It might have helped to post the error he was 
seeing...



I did indeed misread the abbreviation "rev dep" as "revision 
dependencies" rather than "reverse dependencies". (So I thought he was 
submitting revised versions of rJava.) He then sent me a link to the 
original posting from a couple of weeks ago,  which had not been 
threaded correctly on my mail client, so I had no context:


https://stat.ethz.ch/pipermail/r-package-devel/2019q4/004539.html


Apologies for the noise.

--

David




Duncan Murdoch


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

Re: [R-pkg-devel] winbuilder fails for package depending on rJava

[David Winsemius]

On 10/29/19 2:12 PM, Jeff Newmiller wrote:

Once again, you can color me mystified. Are you reading logs not referred to in 
this email thread?


Hi Jeff;

I suppose am reading  else. I ran:

maintainer("rJava")


... and the result was Simon Urbanek's name (which wasn't surprising to 
me), and did not match the name of the OP.


So I was (and am) puzzled that  Kevin was using win-builder on rJava.


--

David.



On October 29, 2019 12:28:59 PM PDT, David Winsemius  
wrote:

On 10/29/19 12:22 PM, Jeff Newmiller wrote:

I suspect David did not read the subject line. This is about

winbuilder [1]. I don't know who runs that service (Uwe?), but this
sounds like they need to investigate.


Correct on the first point, but when I go to that page it says:


Pleasedo notupload packages of other maintainers (particularly not
without changing the Maintainer field to your own e-mail address, if
you
have permissions to do that), because the maintainer indicated in the
maintainer field of the DESCRIPTION file get response from us. Pleasedo

notupload Bioconductor packages or CRAN packages.


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

Re: [R-pkg-devel] winbuilder fails for package depending on rJava

[David Winsemius]

On 10/29/19 12:22 PM, Jeff Newmiller wrote:
> I suspect David did not read the subject line. This is about winbuilder [1]. 
> I don't know who runs that service (Uwe?), but this sounds like they need to 
> investigate.


Correct on the first point, but when I go to that page it says:


Pleasedo notupload packages of other maintainers (particularly not 
without changing the Maintainer field to your own e-mail address, if you 
have permissions to do that), because the maintainer indicated in the 
maintainer field of the DESCRIPTION file get response from us. Pleasedo 
notupload Bioconductor packages or CRAN packages.


-- 

David.

>
> [1] https://win-builder.r-project.org/
>
> On October 29, 2019 9:28:23 AM PDT, David Winsemius  
> wrote:
>> On 10/29/19 4:48 AM, Kevin Kuo wrote:
>>> Seems like all rev deps of rJava are failing Windows checks with the
>> same
>>> error. Might be a Java architecture mismatch issue?
>> Copied from the rJava GitHub page:
>>
>> ==
>>
>>
>>   Bug reports
>>
>> Please userJava GitHub issues page
>> <https://github.com/s-u/rJava/issues><https://github.com/s-u/rJava/issues>
>>
>> to report bugs.
>>
>>
>> (Seems likely that Simon would be aware of such a problem.)
>>
>> 
>>
>>
>> I get no errors in Ubuntu 18.04 with:
>>
>>
>> |install.packages("rJava",,"http://rforge.net;) |
>>
>> You are supposed to offer your OS and other version details with a bug
>> report.

[[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] winbuilder fails for package depending on rJava

[David Winsemius]

On 10/29/19 4:48 AM, Kevin Kuo wrote:

Seems like all rev deps of rJava are failing Windows checks with the same
error. Might be a Java architecture mismatch issue?


Copied from the rJava GitHub page:

==


 Bug reports

Please userJava GitHub issues page 
 
to report bugs.



(Seems likely that Simon would be aware of such a problem.)




I get no errors in Ubuntu 18.04 with:


|install.packages("rJava",,"http://rforge.net;) |

You are supposed to offer your OS and other version details with a bug 
report.



--

David.



[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] What to do when a dependency falls off CRAN

[David Winsemius]

When I attempt to install it the error indicates that the maxent package 
is not available. Attempts to install that package fail with more errors 
than can fit on an Rstudio console, so I cannot even scroll to see the 
first error.


You could simply remove the dependency on that package if your 
application doesn't require the maxent algorithm. Most of the RTextTools 
package is R code.



--

David Winsemius



On 3/24/19 1:00 PM, Neal Fultz wrote:

One of my clients has a shiny app which depends on RTextTools, which was
dropped from CRAN for lack of maintenance.

What would you all recommend in this situation? Here's a couple options I
could think of:

1) Vendor the orphaned package - we are doing this for now. I'm not a fan
of this, because then there's a mix of GPL-2, GPL-3, Apache 2.0 and
proprietary code all in one repo, and because it might encourage other
developers to write monolithic, non-modular code. At least when we find
bugs  we can fix them.

2) Install from CRAN archive instead of CRAN -  good for not having to
carry around third party code in our repo, but I'd expect this to break
with R 3.6, as the package hasn't rolled forward? Also no good way to fix
bugs.

3) Adopt package, push fixed one to CRAN - not sure what the exact process
is for un-orphaning, or if I would want to commit to maintaining it without
knowing more about why it was dropped and how much work it is to get it
passing. Eg if it were pathological solaris memory errors, I might have to
pass. Are there ways to see old automated CRAN checks on a package that was
abandoned? This approach obviously would benefit the community, but this is
probably not billable work.

4) Rewrite - I could do this, but it's probably tedious, weeks of work, and
my client may not want to pay for it; they also may not be interested in
sharing it back if they did.

5) Find another package - then I have to rewrite the "application" code
instead of the "library" code - also sounds tedious, days instead of weeks,
but more likely to be billable.

This topic has come up a few times in the past, but I would like to hear
your current opinions given that CRAN is much more rigorous and automated
now.

v/r

Neal Fultz

[[alternative HTML version deleted]]

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


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

Re: [R-pkg-devel] Puzzled by delay in getting version update on CRAN

[David Winsemius]

> On May 22, 2018, at 8:12 AM, Uwe Ligges <lig...@statistik.tu-dortmund.de> 
> wrote:
> 
> Strange, I see the packages apparead in the queue and was processed 
> automatically, but neither you nor we got a message from the system. Perhaps 
> network problems?
> Can you please submit that version again?
> 

Thanks for the reply. I will do so in a couple of days when I get back to my 
development box.

Best;
David.

> Best,
> Uwe
> 
> 
> On 22.05.2018 13:20, David Winsemius wrote:
>> I'm wondering if I should have gotten an error report for a new version 
>> submission. I submitted the update in an effort to have some of the Notes 
>> corrected. (The Note regarding registering certain compiled routines was not 
>> address. I was testing on a Mac where that issue was not appearing.)  I've 
>> waited a week, thinking that there would be an increased workload around the 
>> release of R 3.5.0.  This was the message I got 7 days ago:
>> #-
>> [This was generated from CRAN.R-project.org/submit.html]
>> The following package was uploaded to CRAN:
>> ===
>> Package Information:
>> Package: muhaz
>> Version: 1.2.7
>> Title: Hazard Function Estimation in Survival Analysis
>> Author(s): S original by Kenneth Hess, <kh...@odin.mdacc.tmc.edu> R port
>> by R. Gentleman
>> Maintainer: David Winsemius <dwinsem...@comcast.net>
>> Depends: R(>= 2.3)
>> Description: Produces a smooth estimate of the hazard function for
>> censored data.
>> License: GPL
>> Imports: survival
>> If this is just caught in a logjam of package revisions, then I'm in no 
>> particular hurry, but if I caused difficulties in my process of submission, 
>> I apologize and will try to submit again.
>> Best;
>> David Winsemius
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] Puzzled by delay in getting version update on CRAN

[David Winsemius]

I'm wondering if I should have gotten an error report for a new version 
submission. I submitted the update in an effort to have some of the Notes 
corrected. (The Note regarding registering certain compiled routines was not 
address. I was testing on a Mac where that issue was not appearing.)  I've 
waited a week, thinking that there would be an increased workload around the 
release of R 3.5.0.  This was the message I got 7 days ago:
#-
[This was generated from CRAN.R-project.org/submit.html]

The following package was uploaded to CRAN:
===

Package Information:
Package: muhaz 
Version: 1.2.7 
Title: Hazard Function Estimation in Survival Analysis 
Author(s): S original by Kenneth Hess, <kh...@odin.mdacc.tmc.edu> R port 
by R. Gentleman 
Maintainer: David Winsemius <dwinsem...@comcast.net> 
Depends: R(>= 2.3) 
Description: Produces a smooth estimate of the hazard function for 
censored data. 
License: GPL 
Imports: survival 

If this is just caught in a logjam of package revisions, then I'm in no 
particular hurry, but if I caused difficulties in my process of submission, I 
apologize and will try to submit again.

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