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

[Cathy Lee Gierke]

I think I have pdflatex.  At least there is a PATH to textbin
> Sys.getenv("PATH")
[1]
"/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin"

Does this path indicate I have pdflatex?

I'm confused because asking about the pdflatex PATH returns a space:
Sys.which("pdflatex")
pdflatex
  ""
What is up with that?

Cathy Lee Gierke


“Those who cannot change their minds cannot change anything.”
*George Bernard Shaw*

“The measure of intelligence is the ability to change.”
*Albert Einstein*




On Fri, Dec 13, 2019 at 6:28 PM David Winsemius 
wrote:

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

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

[R-pkg-devel] pdflatex is not available

[Cathy Lee Gierke]

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

Re: [R-pkg-devel] Error: package or namespace load failed for ‘CATkit’ in namespaceExport

[Cathy Lee Gierke]

This is now fixed.  Not sure why, but I moved a file (that had always
resided in another folder) into the folder most of the other files were in,
and now it works.

Cathy Lee Gierke





On Fri, Dec 13, 2019 at 12:22 PM Cathy Lee Gierke  wrote:

> I am doing the check to build my package:
>
> R CMD check --as-cran CATkit_3.3.9.tar.gz
>
> I get this error:
>
> * checking whether package ‘CATkit’ can be installed ... ERROR
>
> Installation failed.
>
> See ‘/Users/user/CATkit/CATkit.Rcheck/00install.out’ for details.
>
> * DONE
>
>
> The log file says:
> Error: package or namespace load failed for ‘CATkit’ in
> namespaceExport(ns, exports):
>  undefined exports: CatCall, CATCosinor, CATpmc, CATparam
> Error: loading failed
> Execution halted
>
> R console says:
> Saving functions and data ...
> Error in package.skeleton(name = "CATkit", path = "~/CATkit") :
>   generic functions and other S4 objects (e.g., 'CatCall') cannot be
> dumped; use the 'code_files' argument
>
> When I check my R folder, many functions from the package are missing.  So
> the copy is failing.  But the 1st file not copied appears to be in the
> expected location
>
> It has been working until just now, and suddenly I get this.
> Any suggestions where I should look?  Rseek.org doesn't show me any results
> with code_files, nor does R help.
>
> Cathy Lee Gierke
>
>
> “Those who cannot change their minds cannot change anything.”
> *George Bernard Shaw*
>
> “The measure of intelligence is the ability to change.”
> *Albert Einstein*
>
> 
>

[[alternative HTML version deleted]]

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

Re: [Rd] running R with users home dirs on a shared filesystems

[Cook, Malcolm]

Another thing to avoid are having multiple processes simultaneously access 
single sqlite3 database stored on NFS mount.

From sqlite manual: “Your best defense is to not use SQLite for files on a 
network filesystem”

So, if you configuring RStudio Server, make sure to follow advice about RStudio 
Package Manager: “This 
location must exist on local storage”

And any package that uses sqlite “under the hood” will similarly want the db on 
local storage to avoid such issues stemming from multi-process access.

Cheers,
Malcolm

From: R-devel  On Behalf Of Simon Urbanek
Sent: Friday, December 13, 2019 12:52 PM
To: lejeczek 
Cc: r-devel 
Subject: Re: [Rd] running R with users home dirs on a shared filesystems

CAUTION: This email was received from an External Source


User home is not used by R directly, so it is really up to whatever 
package/code may be using user home. In our setup we have all machines using 
NFS mounted homes for years. From experience the only thing to watch for are 
packages that use their own cache directories in $HOME instead of tempdir() - 
it is technically against CRAN policies but we have seen it in the wild.

Cheers,
Simon



> On Dec 13, 2019, at 1:36 PM, lejeczek via R-devel 
> mailto:r-devel@r-project.org>> wrote:
>
> Hi guys,
>
> I want to ask devel for who knows better - having multiple
> nodes serving users home dirs off the same shared network
> filesystem : are there any precautions or must-dos &
> must-donts in order to assure healthy and efficient parallel
> Rs running simultaneously - and I don't mean obvious stuff,
> I'm rather asking about R's internals & environment.
>
> simple example: three nodes mount a NFS share and users on
> all three nodes run R simultaneously.
>
> many thanks, L.
>
> __
> 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] running R with users home dirs on a shared filesystems

[Simon Urbanek]

User home is not used by R directly, so it is really up to whatever 
package/code may be using user home. In our setup we have all machines using 
NFS mounted homes for years. From experience the only thing to watch for are 
packages that use their own cache directories in $HOME instead of tempdir() - 
it is technically against CRAN policies but we have seen it in the wild.

Cheers,
Simon



> On Dec 13, 2019, at 1:36 PM, lejeczek via R-devel  
> wrote:
> 
> Hi guys,
> 
> I want to ask devel for who knows better - having multiple
> nodes serving users home dirs off the same shared network
> filesystem : are there any precautions or must-dos &
> must-donts in order to assure healthy and efficient parallel
> Rs running simultaneously - and I don't mean obvious stuff,
> I'm rather asking about R's internals & environment.
> 
> simple example: three nodes mount a NFS share and users on
> all three nodes run R simultaneously.
> 
> many thanks, L.
> 
> __
> 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: [Bioc-devel] proposal for additional seqlevelsStyle

[Kasper Daniel Hansen]

If the chromosome name depends on the assembly, that makes GenomeInfoDb
even more useful and necessary.  Provided it is supported of course.

On Fri, Dec 13, 2019 at 11:45 AM Vincent Carey 
wrote:

> I tried an inline png but I think it was rejected by bioc-devel.  Here's
> another try.
>
> On Fri, Dec 13, 2019 at 11:40 AM Vincent Carey  >
> wrote:
>
> > Thanks -- It is good to know more about the complications of adding
> > seqlevelsStyle elements.
> > I am not sure how pervasive this will be in SNP annotation in the future.
> > The "new API" for dbSNP
> > references SPDI annotation conventions.
> >
> > https://api.ncbi.nlm.nih.gov/variation/v0/
> >
> > at least one dbsnp build 152 resource uses this nomenclature.  The one
> >
> > referenced below is the "go-to" resource for current rsid-coordinate
> >
> > correspondence, as far as I know.
> >
> >
> > > library(VariantAnnotation)
> >
> > *0/0 packages newly attached/loaded, see sessionInfo() for details.*
> >
> > > mypar = GRanges("NC_01.11", IRanges(10,12)) # note seqnames
> >
> >
> > > nn = readVcf("
> >
> ftp://ftp.ncbi.nih.gov/snp/redesign/latest_release/VCF/GCF_01405.38.gz
> > ",
> >
> > +   genome="GRCh38", param=mypar)
> >
> >
> > > head(rowRanges(nn), 3)
> >
> > GRanges object with 3 ranges and 5 metadata columns:
> >
> >seqnamesranges strand | paramRangeID
> REF
> >
> >   | 
> 
> >
> >   rs1331956057 NC_01.1110  * | 
> C
> >
> >   rs1252351580 NC_01.11100036  * | 
> T
> >
> >   rs1238523913 NC_01.11100051  * | 
> T
> >
> >   ALT  QUAL  FILTER
> >
> >  
> >
> >   rs1331956057  T .
> >
> >   rs1252351580  G .
> >
> >   rs1238523913  C .
> >
> >   ---
> >
> >   seqinfo: 1 sequence from GRCh38 genome; no seqlengths
> >
> >
> > On Fri, Dec 13, 2019 at 11:01 AM Robert Castelo 
> > wrote:
> >
> >> hi Hervé,
> >>
> >> i didn't know about this new sequence style until Vince posted his
> >> message and we briefly talked about it at the European BioC meeting this
> >> week in Brussels. however, i didn't know that the style was specific to
> >> a particular assembly. i have no use case of this at the mome moment,
> >> i.e., i have not encountered myself any annotation or BAM file with
> >> chromosome names written that way, so i don't know how pressing this
> >> issue is, maybe Vince can tell us how spread such chromosome naming
> >> style may become in the near future.
> >>
> >> naively, i'd think that it would be matter of adding a
> >> reference-specific column, i.e., 'GRCh38.p13', 'GRCh37.p13', etc., but i
> >> can imagine that maybe the "reference style" concept might not be the
> >> appropriate placeholder to map all different chromosome names of all
> >> different individual human genomes uploaded to NCBI. maybe we should
> >> wait until we have a specific use case .. Vince?
> >>
> >> robert.
> >>
> >> On 12/11/19 10:06 PM, Pages, Herve wrote:
> >> > Hi Vince, Robert,
> >> >
> >> > Looks like Vince wants the RefSeq accession e.g. NC_17.11 for
> chrom
> >> > 17 in the GRCh38.
> >> >
> >> > @Robert: Is this what you're also interested in?
> >> >
> >> > The problem is that the RefSeq accessions are specific to a particular
> >> > assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but NC_17.10
> for
> >> > the same chrom in GRCh37).
> >> >
> >> > Currently seqlevelsStyle() doesn't know how to distinguish between
> >> > different assemblies of the same organism. Not saying it couldn't but
> it
> >> > would require some thinking and some significant refactoring. It
> >> > wouldn't be just a matter of adding a column to
> >> > genomeStyles()$Homo_sapiens.
> >> >
> >> > H.
> >> >
> >> >
> >> > On 12/10/19 14:19, Robert Castelo wrote:
> >> >> I second this, and would suggest to name the style as 'GRC' for
> "Genome
> >> >> Reference Consortium".
> >> >>
> >> >> thanks Vince for bringing this up, being able to easily switch
> between
> >> >> genome styles is great.
> >> >>
> >> >> if 'paste0()' in R is one of the most influential contributions to
> >> >> statistical computing
> >> >>
> >> >>
> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__simplystatistics.org_2013_01_31_paste0-2Dis-2Dstatistical-2Dcomputings-2Dmost-2Dinfluential-2Dcontribution-2Dof-2Dthe-2D21st-2Dcentury=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=b0_SIu8orJ7ZcCS3TIodFvGTPibt9R8vFL5Y40YSx3Q=
> >> >>
> >> >> i think that 'seqlevelsStyle()' from the GenomeInfoDb package is one
> of
> >> >> the most influential contributions to human genetics, if you think
> >> about
> >> >> the time invested by researchers in parsing and changing between
> >> >> different styles of chromosome names :)
> >> >>
> >> >> robert.
> >> >>
> >> >> 

Re: [Rd] Build failure on powerpc64

[Tom Callaway]

No, that does not change the issue:

arithmetic.c:180:26: error: initializer element is not constant
  180 | static LDOUBLE q_1_eps = 1.L / LDBL_EPSILON;

Tom

On Fri, Dec 13, 2019 at 11:56 AM Serguei Sokol 
wrote:

> Le 13/12/2019 à 17:06, Tom Callaway a écrit :
> > arithmetic.c:
> > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> Just a thought: can it be that it's "1" which is at the origin of
> compiler complaint?
> In this case, would the syntax "1.L" be sufficient to keep it calm?
>
> Serguei.
>
>

[[alternative HTML version deleted]]

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

[Rd] running R with users home dirs on a shared filesystems

[lejeczek via R-devel]

Hi guys,

I want to ask devel for who knows better - having multiple
nodes serving users home dirs off the same shared network
filesystem : are there any precautions or must-dos &
must-donts in order to assure healthy and efficient parallel
Rs running simultaneously - and I don't mean obvious stuff,
I'm rather asking about R's internals & environment.

simple example: three nodes mount a NFS share and users on
all three nodes run R simultaneously.

many thanks, L.

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

[R-pkg-devel] Error: package or namespace load failed for ‘CATkit’ in namespaceExport

[Cathy Lee Gierke]

I am doing the check to build my package:

R CMD check --as-cran CATkit_3.3.9.tar.gz

I get this error:

* checking whether package ‘CATkit’ can be installed ... ERROR

Installation failed.

See ‘/Users/user/CATkit/CATkit.Rcheck/00install.out’ for details.

* DONE


The log file says:
Error: package or namespace load failed for ‘CATkit’ in namespaceExport(ns,
exports):
 undefined exports: CatCall, CATCosinor, CATpmc, CATparam
Error: loading failed
Execution halted

R console says:
Saving functions and data ...
Error in package.skeleton(name = "CATkit", path = "~/CATkit") :
  generic functions and other S4 objects (e.g., 'CatCall') cannot be
dumped; use the 'code_files' argument

When I check my R folder, many functions from the package are missing.  So
the copy is failing.  But the 1st file not copied appears to be in the
expected location

It has been working until just now, and suddenly I get this.
Any suggestions where I should look?  Rseek.org doesn't show me any results
with code_files, nor does R help.

Cathy Lee Gierke


“Those who cannot change their minds cannot change anything.”
*George Bernard Shaw*

“The measure of intelligence is the ability to change.”
*Albert Einstein*



[[alternative HTML version deleted]]

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

Re: [Rd] tempdir() containing spaces breaks installing source packages

[William Dunlap via R-devel]

You might expand the scope of this a bit to include Windows usernames with
non-ASCII characters in them.  If I recall correctly, if you are logged
under a Cyrillic UTF-8 name then R will not even start.  We have seen this
in the wild.

Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Fri, Dec 13, 2019 at 8:47 AM Ivan Krylov  wrote:

> Hello everyone!
>
> Temp paths are used in system2() calls without shQuote() because
> they are assumed not to contain spaces. On Windows,
> GetShortPathName() is used to try to ensure that.
>
> Unfortunately, sometimes GetShortPathName() silently fails to return a
> 8.3 file path and gives a full path instead (8.3 file names might be
> disabled on newer Windows 10 installations, or there may be another
> reason). This has been spotted in the wild [*]. When %USERPROFILE%
> contains spaces, this results in tempdir() also containing spaces and
> prevents the user from being able to install source packages.
>
> As of ,
>
>  - src/library/utils/R/packages2.R line 839 contains an unquoted
>temporary file path (fil) passed to system2(), which results in it
>being split and R CMD INSTALL not being able to find the package
>file. In other invocations of R CMD INSTALL in the same file, the
>path is properly quoted.
>
>  - src/library/tools/R/check.R line 125 contains an unquoted temporary
>file path passed to system2, which results in Rterm.exe -f not being
>able to find the RtmpXX\Rin file, causing the attempt to
>run tools:::makeLazyLoading(...) to fail.
>
> I can report these two problems (thanks to Martin Maechler for the
> Bugzilla account and the advice) and attach the patches required to fix
> them, but there might be more. The bug report [**] is somewhat relevant
> here (though changing the default behaviour of system2() is obviously
> not the right solution as it would break existing code).
>
> Is there anything I should consider before creating the PR as
> described above?
>
> --
> Best regards,
> Ivan
>
> [*] https://stat.ethz.ch/pipermail/r-help/2019-December/465075.html
>
> [**] https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16127
>
> __
> 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

[Rd] tempdir() containing spaces breaks installing source packages

[Ivan Krylov]

Hello everyone!

Temp paths are used in system2() calls without shQuote() because
they are assumed not to contain spaces. On Windows,
GetShortPathName() is used to try to ensure that.

Unfortunately, sometimes GetShortPathName() silently fails to return a
8.3 file path and gives a full path instead (8.3 file names might be
disabled on newer Windows 10 installations, or there may be another
reason). This has been spotted in the wild [*]. When %USERPROFILE%
contains spaces, this results in tempdir() also containing spaces and
prevents the user from being able to install source packages.

As of ,

 - src/library/utils/R/packages2.R line 839 contains an unquoted
   temporary file path (fil) passed to system2(), which results in it
   being split and R CMD INSTALL not being able to find the package
   file. In other invocations of R CMD INSTALL in the same file, the
   path is properly quoted.

 - src/library/tools/R/check.R line 125 contains an unquoted temporary
   file path passed to system2, which results in Rterm.exe -f not being
   able to find the RtmpXX\Rin file, causing the attempt to
   run tools:::makeLazyLoading(...) to fail.

I can report these two problems (thanks to Martin Maechler for the
Bugzilla account and the advice) and attach the patches required to fix
them, but there might be more. The bug report [**] is somewhat relevant
here (though changing the default behaviour of system2() is obviously
not the right solution as it would break existing code).

Is there anything I should consider before creating the PR as
described above?

-- 
Best regards,
Ivan

[*] https://stat.ethz.ch/pipermail/r-help/2019-December/465075.html

[**] https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16127

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

Re: [Bioc-devel] proposal for additional seqlevelsStyle

[Vincent Carey]

I tried an inline png but I think it was rejected by bioc-devel.  Here's
another try.

On Fri, Dec 13, 2019 at 11:40 AM Vincent Carey 
wrote:

> Thanks -- It is good to know more about the complications of adding
> seqlevelsStyle elements.
> I am not sure how pervasive this will be in SNP annotation in the future.
> The "new API" for dbSNP
> references SPDI annotation conventions.
>
> https://api.ncbi.nlm.nih.gov/variation/v0/
>
> at least one dbsnp build 152 resource uses this nomenclature.  The one
>
> referenced below is the "go-to" resource for current rsid-coordinate
>
> correspondence, as far as I know.
>
>
> > library(VariantAnnotation)
>
> *0/0 packages newly attached/loaded, see sessionInfo() for details.*
>
> > mypar = GRanges("NC_01.11", IRanges(10,12)) # note seqnames
>
>
> > nn = readVcf("
> ftp://ftp.ncbi.nih.gov/snp/redesign/latest_release/VCF/GCF_01405.38.gz
> ",
>
> +   genome="GRCh38", param=mypar)
>
>
> > head(rowRanges(nn), 3)
>
> GRanges object with 3 ranges and 5 metadata columns:
>
>seqnamesranges strand | paramRangeIDREF
>
>   |  
>
>   rs1331956057 NC_01.1110  * |   C
>
>   rs1252351580 NC_01.11100036  * |   T
>
>   rs1238523913 NC_01.11100051  * |   T
>
>   ALT  QUAL  FILTER
>
>  
>
>   rs1331956057  T .
>
>   rs1252351580  G .
>
>   rs1238523913  C .
>
>   ---
>
>   seqinfo: 1 sequence from GRCh38 genome; no seqlengths
>
>
> On Fri, Dec 13, 2019 at 11:01 AM Robert Castelo 
> wrote:
>
>> hi Hervé,
>>
>> i didn't know about this new sequence style until Vince posted his
>> message and we briefly talked about it at the European BioC meeting this
>> week in Brussels. however, i didn't know that the style was specific to
>> a particular assembly. i have no use case of this at the mome moment,
>> i.e., i have not encountered myself any annotation or BAM file with
>> chromosome names written that way, so i don't know how pressing this
>> issue is, maybe Vince can tell us how spread such chromosome naming
>> style may become in the near future.
>>
>> naively, i'd think that it would be matter of adding a
>> reference-specific column, i.e., 'GRCh38.p13', 'GRCh37.p13', etc., but i
>> can imagine that maybe the "reference style" concept might not be the
>> appropriate placeholder to map all different chromosome names of all
>> different individual human genomes uploaded to NCBI. maybe we should
>> wait until we have a specific use case .. Vince?
>>
>> robert.
>>
>> On 12/11/19 10:06 PM, Pages, Herve wrote:
>> > Hi Vince, Robert,
>> >
>> > Looks like Vince wants the RefSeq accession e.g. NC_17.11 for chrom
>> > 17 in the GRCh38.
>> >
>> > @Robert: Is this what you're also interested in?
>> >
>> > The problem is that the RefSeq accessions are specific to a particular
>> > assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but NC_17.10 for
>> > the same chrom in GRCh37).
>> >
>> > Currently seqlevelsStyle() doesn't know how to distinguish between
>> > different assemblies of the same organism. Not saying it couldn't but it
>> > would require some thinking and some significant refactoring. It
>> > wouldn't be just a matter of adding a column to
>> > genomeStyles()$Homo_sapiens.
>> >
>> > H.
>> >
>> >
>> > On 12/10/19 14:19, Robert Castelo wrote:
>> >> I second this, and would suggest to name the style as 'GRC' for "Genome
>> >> Reference Consortium".
>> >>
>> >> thanks Vince for bringing this up, being able to easily switch between
>> >> genome styles is great.
>> >>
>> >> if 'paste0()' in R is one of the most influential contributions to
>> >> statistical computing
>> >>
>> >>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__simplystatistics.org_2013_01_31_paste0-2Dis-2Dstatistical-2Dcomputings-2Dmost-2Dinfluential-2Dcontribution-2Dof-2Dthe-2D21st-2Dcentury=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=b0_SIu8orJ7ZcCS3TIodFvGTPibt9R8vFL5Y40YSx3Q=
>> >>
>> >> i think that 'seqlevelsStyle()' from the GenomeInfoDb package is one of
>> >> the most influential contributions to human genetics, if you think
>> about
>> >> the time invested by researchers in parsing and changing between
>> >> different styles of chromosome names :)
>> >>
>> >> robert.
>> >>
>> >> On 06/12/2019 15:03, Vincent Carey wrote:
>> >>> I raised this issue previously with little response.
>> >>>
>> >>> I'd propose that we add a column or two to genomeStyles()$Homo_sapiens
>> >>>
>>  head(genomeStyles()$Homo_sapiens, 2)
>> >>> circular auto   sex NCBI UCSC dbSNP Ensembl
>> >>>
>> >>> 1FALSE TRUE FALSE1 chr1   ch1   1
>> >>>
>> >>> 2FALSE TRUE FALSE2 chr2   ch2   2
>> >>>
>> >>>
>> >>> 

Re: [Rd] Build failure on powerpc64

[Serguei Sokol]

Le 13/12/2019 à 17:06, Tom Callaway a écrit :

arithmetic.c:
static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
Just a thought: can it be that it's "1" which is at the origin of 
compiler complaint?

In this case, would the syntax "1.L" be sufficient to keep it calm?

Serguei.

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

Re: [Rd] Build failure on powerpc64

[Tom Callaway]

An excellent question. It is important to remember two key facts:

1. With gcc on ppc64, long doubles exist, they can be used, just not safely
as constants (and maybe they still can be used safely under specific
conditions?).
2. I am not an expert in either PowerPC64 or gcc. :)

Looking at connections.c, we have (in order):
  * handling long double as a valid case in a switch statement checking size
  * adding long double as a field in the u union define
  * handling long double as a valid case in a switch statement checking size
  * handling long double as a valid case in a switch statement checking size
  * memcpy from the address of a long double

In format.c, we have (in order):
  * conditionally creating private_nearbyintl for R_nearbyintl
  * defining a static const long double tbl[]
  * use exact scaling factor in long double precision

For most of these, it seems safe to leave them as is for ppc64. I would
have thought that the gcc compiler might have had issue with:

connections.c:
  static long double ld1;
for (i = 0, j = 0; i < len; i++, j += size) {
ld1 = (long double) REAL(object)[i];

format.c:
   static const long double tbl[] =

... but it doesn't. Perhaps the original code at issue:

arithmetic.c:
   static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;

only makes gcc unhappy because of the very large value trying to be stored
in the static long double, which would make it span the "folded double" on
that architecture.

*

It seems that the options are:

A) Patch the one place where the compiler determines it is not safe to use
a static long double on ppc64.
B) Treat PPC64 as a platform where it is never safe to use a static long
double

FWIW, I did run the test suite after applying my patch and all of the tests
pass on ppc64.

Tom


On Fri, Dec 13, 2019 at 5:44 AM Martin Maechler 
wrote:

> > Tom Callaway
> > on Thu, 12 Dec 2019 14:21:10 -0500 writes:
>
> > Hi R folks,
>
> > Went to build R 3.6.2 for Fedora/EPEL and got failures across the
> board.
>
> > Disabling the test suite for all non-intel architectures resolves
> most of
> > the failures, but powerpc64 dies in the compiler, specifically here:
>
> > gcc -m64  -I../../src/extra/xdr -I. -I../../src/include
> -I../../src/include
> > -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp
> -fPIC
> > -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> > -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> > -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8
> > -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection
> -c
> > arithmetic.c -o arithmetic.o
> > arithmetic.c:180:26: error: initializer element is not constant
> > 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON);
> > |  ^
> > make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1
>
> > Took me a bit to figure out why, but this is happening because on
> > powerpc64, gcc is compiled with -mlong-double-128, and the long
> double
> > format used on PPC is IBM's 128bit long double which is two doubles
> added
> > together. As a result, gcc can't safely do const assignments to long
> > doubles on ppc64, so it dies there.
>
> > The fix is easy enough, do not try to assign a value to a static long
> > double on ppc64.
> > --- ./src/main/arithmetic.c.orig2019-12-12
> 18:30:12.416334062 +
> > +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +
> > @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> > #endif
> > }
>
> > -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> > +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> > + * of issues constant folding 128bit IBM long doubles.
> > + */
> > +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) &&
> !__PPC64__
> > static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> > #else
> > static double  q_1_eps = 1 / DBL_EPSILON;
>
>
> > Hope that helps someone else.
> > Tom
>
> Thank you, Tom.  That is "interesting"  ...
>
> The piece in question had been added by me,
> 
> r77193 | maechler | 2019-09-18 13:21:49 +0200 (Wed, 18 Sep 2019) | 1 line
>
>  x %% +/- Inf  now typically return non-NaN; fix the "FIXME" in C
> 
> in order to use double precision in order to deal with finite cases
> close to Inf, etc.
>
> IIUC, your proposed patch is really a workaround a bug on PPC64 ?
>
> But note the check on LONG_DOUBLE is not the only one in R's
> sources: Via 'grep' in src/main/*.?  I also see
>
> connections.c 4285:#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE >
> SIZEOF_DOUBLE)

Re: [Bioc-devel] proposal for additional seqlevelsStyle

[Robert Castelo]

hi Hervé,

i didn't know about this new sequence style until Vince posted his 
message and we briefly talked about it at the European BioC meeting this 
week in Brussels. however, i didn't know that the style was specific to 
a particular assembly. i have no use case of this at the mome moment, 
i.e., i have not encountered myself any annotation or BAM file with 
chromosome names written that way, so i don't know how pressing this 
issue is, maybe Vince can tell us how spread such chromosome naming 
style may become in the near future.


naively, i'd think that it would be matter of adding a 
reference-specific column, i.e., 'GRCh38.p13', 'GRCh37.p13', etc., but i 
can imagine that maybe the "reference style" concept might not be the 
appropriate placeholder to map all different chromosome names of all 
different individual human genomes uploaded to NCBI. maybe we should 
wait until we have a specific use case .. Vince?


robert.

On 12/11/19 10:06 PM, Pages, Herve wrote:

Hi Vince, Robert,

Looks like Vince wants the RefSeq accession e.g. NC_17.11 for chrom
17 in the GRCh38.

@Robert: Is this what you're also interested in?

The problem is that the RefSeq accessions are specific to a particular
assembly (e.g. NC_17.11 for chrom 17 in GRCh38 but NC_17.10 for
the same chrom in GRCh37).

Currently seqlevelsStyle() doesn't know how to distinguish between
different assemblies of the same organism. Not saying it couldn't but it
would require some thinking and some significant refactoring. It
wouldn't be just a matter of adding a column to
genomeStyles()$Homo_sapiens.

H.


On 12/10/19 14:19, Robert Castelo wrote:

I second this, and would suggest to name the style as 'GRC' for "Genome
Reference Consortium".

thanks Vince for bringing this up, being able to easily switch between
genome styles is great.

if 'paste0()' in R is one of the most influential contributions to
statistical computing

https://urldefense.proofpoint.com/v2/url?u=https-3A__simplystatistics.org_2013_01_31_paste0-2Dis-2Dstatistical-2Dcomputings-2Dmost-2Dinfluential-2Dcontribution-2Dof-2Dthe-2D21st-2Dcentury=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=b0_SIu8orJ7ZcCS3TIodFvGTPibt9R8vFL5Y40YSx3Q=

i think that 'seqlevelsStyle()' from the GenomeInfoDb package is one of
the most influential contributions to human genetics, if you think about
the time invested by researchers in parsing and changing between
different styles of chromosome names :)

robert.

On 06/12/2019 15:03, Vincent Carey wrote:

I raised this issue previously with little response.

I'd propose that we add a column or two to genomeStyles()$Homo_sapiens


head(genomeStyles()$Homo_sapiens, 2)

    circular auto   sex NCBI UCSC dbSNP Ensembl

1    FALSE TRUE FALSE    1 chr1   ch1   1

2    FALSE TRUE FALSE    2 chr2   ch2   2


that includes the values for "NCBI reference sequence names"

See
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_nuccore_568815581=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=3Jy-MH7heIcrc_A4qm_izduLvBoPWHSeq4gdxf5nv24=
for one report on chr17,
and

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ncbi.nlm.nih.gov_assembly_GCF-5F01405.39=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=y6ut_Xcc4rSbXanckiJhiwLsL0W8neJfKWQa6wnG3aM=

for a table that includes the Genbank labels.

Should I just file a PR at
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Bioconductor_GenomeInfoDb_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=KMzfo3_8kkJ-wdvRCNP5rUjTVMW87brj07yHaKL5Qb0=
after
testing?



___
Bioc-devel@r-project.org mailing list
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LCcYSINIz3XXhf8i-26IegXRLkTO1NgVbvzgvnPA3dc=SvtNreKVOHnSGjsRwzWWpttpEF7wBXI5utI37-qgX1A=





--
Robert Castelo, PhD
Associate Professor
Dept. of Experimental and Health Sciences
Universitat Pompeu Fabra (UPF)
Barcelona Biomedical Research Park (PRBB)
Dr Aiguader 88
E-08003 Barcelona, Spain
telf: +34.933.160.514
fax: +34.933.160.550

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

Re: [R-pkg-devel] Problem with placeholer title 'Vignette Tiitle'

[Max Turgeon]

You can fix the note by giving an actual tityto your vignette, which you can do 
by changing the following line in your YAML header:
 %\VignetteIndexEntry{Vignette Title}

Max

On Dec 13, 2019 8:16 AM, olivier martin  wrote:
Dear all,

I am trying to update the "siland" package with a new version. In this
new version, I have introduced a
vignette. By using the command R CMD check --as-cran, I have no error
message, but when I submit the
new version I get a NOTE:
Vignette package with placeholder title 'Vignette Title':
'Siland.Rmd'

So, how to avoid this NOTE ?

Here is the beginning of the vignette:

---
author : "Florence Carpentier and Olivier Martin"
date: "`r Sys.Date()`"
output:
   html_document:
  fig_caption: false
  toc: true
  toc_float:
collapsed: false
smooth_scroll: false
  toc_depth: 3
vignette: >
%\VignetteIndexEntry{Vignette Title}
%\VignetteEngine{knitr::rmarkdown}
\usepackage[utf8]{inputenc}
---

```{r echo = FALSE, message = FALSE}
knitr::opts_chunk$set(collapse=T,
cache=T,
eval = F)
#knitr::opts_chunk$set(eval = FALSE)
# options(width = 120, max.print = 100)
```


Thanks for your help,
Olivier.

--
--
MARTIN Olivier
INRA Centre de recherche PACA
228 route de l'A�rodrome
Unit� Biostatistique & Processus Spatiaux
CS 40509
Domaine St Paul, Site Agroparc
84914 Avignon Cedex 9, France
Tel : 04 32 72 21 57

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

[[alternative HTML version deleted]]

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

[R-pkg-devel] Problem with placeholer title 'Vignette Tiitle'

[olivier martin]

Dear all,

I am trying to update the "siland" package with a new version. In this
new version, I have introduced a
vignette. By using the command R CMD check --as-cran, I have no error
message, but when I submit the
new version I get a NOTE:
Vignette package with placeholder title 'Vignette Title':
'Siland.Rmd'

So, how to avoid this NOTE ?

Here is the beginning of the vignette:

---
author : "Florence Carpentier and Olivier Martin"
date: "`r Sys.Date()`"
output:
  html_document:
     fig_caption: false
     toc: true
     toc_float:
   collapsed: false
   smooth_scroll: false
     toc_depth: 3
vignette: >
   %\VignetteIndexEntry{Vignette Title}
   %\VignetteEngine{knitr::rmarkdown}
   \usepackage[utf8]{inputenc}
---

```{r echo = FALSE, message = FALSE}
knitr::opts_chunk$set(collapse=T,
   cache=T,
   eval = F)
#knitr::opts_chunk$set(eval = FALSE)
# options(width = 120, max.print = 100)
```


Thanks for your help,
Olivier.

--
--
MARTIN Olivier
INRA Centre de recherche PACA
228 route de l'Aérodrome
Unité Biostatistique & Processus Spatiaux
CS 40509
Domaine St Paul, Site Agroparc
84914 Avignon Cedex 9, France
Tel : 04 32 72 21 57

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

Re: [Rd] Build failure on powerpc64

[Martin Maechler]

> Tom Callaway 
> on Thu, 12 Dec 2019 14:21:10 -0500 writes:

> Hi R folks,

> Went to build R 3.6.2 for Fedora/EPEL and got failures across the board.

> Disabling the test suite for all non-intel architectures resolves most of
> the failures, but powerpc64 dies in the compiler, specifically here:

> gcc -m64  -I../../src/extra/xdr -I. -I../../src/include 
-I../../src/include
> -I/usr/local/include -I../../src/nmath -DHAVE_CONFIG_H   -fopenmp -fPIC
> -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8
> -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection  -c
> arithmetic.c -o arithmetic.o
> arithmetic.c:180:26: error: initializer element is not constant
> 180 | static LDOUBLE q_1_eps = (1 / LDBL_EPSILON);
> |  ^
> make[3]: *** [../../Makeconf:124: arithmetic.o] Error 1

> Took me a bit to figure out why, but this is happening because on
> powerpc64, gcc is compiled with -mlong-double-128, and the long double
> format used on PPC is IBM's 128bit long double which is two doubles added
> together. As a result, gcc can't safely do const assignments to long
> doubles on ppc64, so it dies there.

> The fix is easy enough, do not try to assign a value to a static long
> double on ppc64.
> --- ./src/main/arithmetic.c.orig2019-12-12 18:30:12.416334062 
+
> +++ ./src/main/arithmetic.c 2019-12-12 18:30:44.966334062 +
> @@ -179,7 +179,10 @@ void attribute_hidden InitArithmetic()
> #endif
> }

> -#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
> +/* PowerPC 64 (when gcc has -mlong-double-128) breaks here because
> + * of issues constant folding 128bit IBM long doubles.
> + */
> +#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) && 
!__PPC64__
> static LDOUBLE q_1_eps = 1 / LDBL_EPSILON;
> #else
> static double  q_1_eps = 1 / DBL_EPSILON;


> Hope that helps someone else.
> Tom

Thank you, Tom.  That is "interesting"  ...

The piece in question had been added by me,

r77193 | maechler | 2019-09-18 13:21:49 +0200 (Wed, 18 Sep 2019) | 1 line

 x %% +/- Inf  now typically return non-NaN; fix the "FIXME" in C

in order to use double precision in order to deal with finite cases
close to Inf, etc.

IIUC, your proposed patch is really a workaround a bug on PPC64 ?

But note the check on LONG_DOUBLE is not the only one in R's
sources: Via 'grep' in src/main/*.?  I also see

connections.c4285:#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
connections.c4329:#if HAVE_LONG_DOUBLE
connections.c4379:#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
connections.c4514:#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
connections.c4592:#if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE)
format.c250:#if defined(HAVE_LONG_DOUBLE) && (SIZEOF_LONG_DOUBLE > 
SIZEOF_DOUBLE)
format.c285:#if defined(HAVE_LONG_DOUBLE) && (SIZEOF_LONG_DOUBLE > 
SIZEOF_DOUBLE)
format.c339:#if defined(HAVE_LONG_DOUBLE) && (SIZEOF_LONG_DOUBLE > 
SIZEOF_DOUBLE)

Do they also need protection against this PPC64 bug ?

Best,

Martin Maechler
ETH Zurich and R Core Team
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel