Re: [R-pkg-devel] CRAN submission - Specified C++11
Dear Riccardo, See, for example, here: https://github.com/mlpack/mlpack/issues/3407 As explained there (https://github.com/mlpack/mlpack/issues/3407#issuecomment-1426249703) "R 4.1.0, the base of the current r-oldrel (aka "previous release") already defaulted to C++14." So, unless you really need C++11 and cannot use newer standards, you can probably remove CXX_STD = CXX11 Best, R. On Mon, 27-February-2023, at 10:25:55, Riccardo Di Francesco wrote: > Dear R-developers, > > I apologize if this issue has been already resolved, I could not find any > solution in your archives. > > I recently submitted a package to CRAN. In the "src/Makevars" file I > put CXX_STD > = CXX11 to specify C++11 code. This causes my package to fail the automatic > checks, which raise the following note: > > *"checking C++ specification ... NOTE* > * Specified C++11: please drop specification unless essential"* > > Specifying C++11 is necessary to make my package work. How can I solve > this? > > Best -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-31 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com r.d...@uam.es ramon.d...@iib.uam.es https://ligarto.org/rdiaz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] Mac ARM64 binaries available
On Tue, 04-October-2022, at 21:21:33, Hervé Pagès wrote: > Hi Ramon, > > FWIW here's what I get when I run code chunk fdfmutex2 from the OncoSimulR.Rmd > vignette on kjohnson (Mac arm64): Thanks a lot! > >> set.seed(1) > >> s2fd <- oncoSimulIndiv(afe4, > + muEF = mtfd, > + model = "McFL", > + onlyCancer = FALSE, > + finalTime = 40, > + mu = 1e-4, > + initSize = 5000, > + keepPhylog = TRUE, > + seed = NULL, > + errorHitMaxTries = FALSE, > + errorHitWallTime = FALSE) > Using old version of fitnessEffects. Transforming fitnessEffects > to last version. > Using old version of fitnessEffects. Transforming fitnessEffects > to last version. > Using old version of fitnessEffects. Transforming fitnessEffects > to last version. > Using old version of fitnessEffects. Transforming fitnessEffects > to last version. > > ERROR: Algo 2: (1.0 - pe/pm) > 1.0 > > Unrecoverable exception: Algo 2: 1 - pe/pm > 1. Aborting. > >> plot(s2fd, show = "genotypes") > Error in seq.int(0, 1, length.out = n) : > 'length.out' must be a non-negative number > > So it looks like the real error actually occurs in oncoSimulIndiv(). This > function relies heavily on C++ code. Yes, that is an exception thrown from the C++ code. In the particular scenario simulated here it could in principle happen; however, with these same parameters, after running the code with 20 different random seeds (under Linux, and two different versions of gcc/g++; so 40 runs, actually) it did not happen even once. So I think this suggests there is something else going on. I'd have to get the vignette to pass (maybe disabling this specific example in this architecture) so that, once also output from tests is given for this architecture, I can look at the output from tests. But I'd rather not touch anything not absolutely necessary right now, given we are getting close to the release of BioC 3.16. > > An orthogonal issue is that oncoSimulIndiv() shouldn't catch the error like it > does right now. Problem with this design is that the function seems to return > normally but the returned object is broken. Would be better if the error was > actually a hard one i.e. if the call to oncoSimulIndiv() actually failed. > Yes, you are right. I'll have to think about how to deal with this. Returning an object that includes information about the exception can be argued that makes sense; this is what I do now (e.g., this code is also called from other functions, that have ad-hoc procedures for dealing with objects from runs that threw exceptions). My implicit assumption was "As soon as the user sees the Unrecoverable exception, they will not try to do a plot". But this is obviously not a good way to do it, as I can see :-) . My bad. Thanks a lot again. Best, R. > Cheers, > > H. > > > On 04/10/2022 03:45, Ramon Diaz-Uriarte wrote: >> Dear Vincent, >> >> On Tue, 04-October-2022, at 11:40:11, Vincent Carey >> wrote: >>> We are not running check on ARM platform at this time. If you want to >>> provide >>> a link >>> to the >>> package/error you are having trouble with I will have a look on my machine. >> Thanks a lot. This is the link: >> >> https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/OncoSimulR/kjohnson-buildsrc.html >> >> To try to figure it out, I split the suspected problematic section of the >> vignette where things fail; the newest version of the package (as well as the >> former one) passed checks in the other platforms. >> >> Nevertheless, since not passing in this platform will have no consequences, I >> would not like to bug you with this. Since there is no rush, I'll use >> trial-and-error, preparing new versions as new check results become >> available. >> >> >> Best, >> >> >> R. >> >> >>> If you are >>> passing >>> on the other platforms there will be no consequences for remaining in the >>> bioc >>> ecosystem. >>> >>> On Tue, Oct 4, 2022 at 5:22 AM Ramon Diaz-Uriarte wrote: >>> >>> Dear All, >>> >>> It is unclear to me if the deadline of 28-October-2022 for "packages >>> passing >>> ‘‘R >>> CMD build’’ and ‘‘R CMD check’’ without errors or warnings" >>> (https://bioconductor.org/developers/release-schedule/) also
Re: [Bioc-devel] Mac ARM64 binaries available
Dear Vincent, On Tue, 04-October-2022, at 11:40:11, Vincent Carey wrote: > We are not running check on ARM platform at this time. If you want to > provide a link > to the > package/error you are having trouble with I will have a look on my machine. Thanks a lot. This is the link: https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/OncoSimulR/kjohnson-buildsrc.html To try to figure it out, I split the suspected problematic section of the vignette where things fail; the newest version of the package (as well as the former one) passed checks in the other platforms. Nevertheless, since not passing in this platform will have no consequences, I would not like to bug you with this. Since there is no rush, I'll use trial-and-error, preparing new versions as new check results become available. Best, R. > If you are > passing > on the other platforms there will be no consequences for remaining in the bioc > ecosystem. > > On Tue, Oct 4, 2022 at 5:22 AM Ramon Diaz-Uriarte wrote: > > Dear All, > > It is unclear to me if the deadline of 28-October-2022 for "packages passing > ‘‘R > CMD build’’ and ‘‘R CMD check’’ without errors or warnings" > (https://bioconductor.org/developers/release-schedule/) also applies to this > platform. > > Why the question? I am trying to debug an error in this platform of a > package I > maintain but: > > a) the snapshot date seems older than the snapshot date in > http://bioconductor.org/checkResults/devel/bioc-LATEST/ (which would > introduce a longer delay in verifying results of code changes) > > b) results are not linked from the former page (which, I understand, is the > "canonical" one for checking status). > > Thanks, > > R. > > On Tue, 27-September-2022, at 19:46:01, Jennifer Wokaty > wrote: > > Mac ARM64 binaries are now available. You can view the build report at > > https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/. > > > > To make use of these binaries > > > > * Install R-4.2.1-arm64.pkg from CRAN at > https://cran.r-project.org/bin/macosx/ > > * Install BiocManager as usual > > * Use BiocManager::install() as usual > > > > Note: BiocManager::install() will automatically pick the new arm64 > binaries so > > you should no longer need Xcode. > > > > > > Jennifer Wokaty > > they/them > > Bioconductor Core Team > > CUNY SPH > > > > [[alternative HTML version deleted]] > > > > ___ > > Bioc-devel@r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > -- > Ramon Diaz-Uriarte > Department of Biochemistry, Lab B-31 > Facultad de Medicina > Universidad Autónoma de Madrid > Arzobispo Morcillo, 4 > 28029 Madrid > Spain > > Phone: +34-91-497-2412 > > Email: rdia...@gmail.com > r.d...@uam.es > > https://ligarto.org/rdiaz > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > > The information in this e-mail is intended only for the person to whom it is > addressed. If you believe this e-mail was sent to you in error and the e-mail > contains patient information, please contact the Partners Compliance HelpLine > at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-31 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com r.d...@uam.es https://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Mac ARM64 binaries available
Dear All, It is unclear to me if the deadline of 28-October-2022 for "packages passing ‘‘R CMD build’’ and ‘‘R CMD check’’ without errors or warnings" (https://bioconductor.org/developers/release-schedule/) also applies to this platform. Why the question? I am trying to debug an error in this platform of a package I maintain but: a) the snapshot date seems older than the snapshot date in http://bioconductor.org/checkResults/devel/bioc-LATEST/ (which would introduce a longer delay in verifying results of code changes) b) results are not linked from the former page (which, I understand, is the "canonical" one for checking status). Thanks, R. On Tue, 27-September-2022, at 19:46:01, Jennifer Wokaty wrote: > Mac ARM64 binaries are now available. You can view the build report at > https://bioconductor.org/checkResults/3.16/bioc-mac-arm64-LATEST/. > > To make use of these binaries > > * Install R-4.2.1-arm64.pkg from CRAN at > https://cran.r-project.org/bin/macosx/ > * Install BiocManager as usual > * Use BiocManager::install() as usual > > Note: BiocManager::install() will automatically pick the new arm64 binaries so > you should no longer need Xcode. > > > Jennifer Wokaty > they/them > Bioconductor Core Team > CUNY SPH > > [[alternative HTML version deleted]] > > ___ > Bioc-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-31 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com r.d...@uam.es https://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] riesling1: some package that install, build, check, and build bin OK, shown in red
Thanks Martin and Lori, and sorry for the noise: it did not occur to me to mouse over the red dot. Best, R. On Wed, 07-July-2021, at 16:06:15, Martin Morgan wrote: > Mousing over the red dot provides an explanation, e.g., for OncoSimulR "NO, > package depends on 'Rgraphviz' which is not available." Rgraphviz is indeed > failing on all three platforms, but from the landing page it has propagated > some time this release for Linux and macOS and so OncoSimulR can also > propagate for these platforms. > > Martin > > On 7/7/21, 8:15 AM, "Bioc-devel on behalf of Kern, Lori" > > wrote: > > Normally the red dot prevents propagation due to conditions that would > not allow the package to function properly such as dependencies not being > available, or a requested version of a package is not yet available. > > > > > Lori Shepherd > > Bioconductor Core Team > > Roswell Park Comprehensive Cancer Center > > Department of Biostatistics & Bioinformatics > > Elm & Carlton Streets > > Buffalo, New York 14263 > > > From: Bioc-devel on behalf of Ramon > Diaz-Uriarte > Sent: Wednesday, July 7, 2021 7:18 AM > To: bioc-devel@r-project.org > Cc: r.d...@uam.es > Subject: [Bioc-devel] riesling1: some package that install, build, check, > and build bin OK, shown in red > > > Dear All, > > In BioC 3.14, with riesling1, some packages that are shown as OK in > Install, Build, Check, and Build bin, show, however a red dot, and have no > zip. Some examples are (the first one I maintain; the rest I just picked > randomly): > > > > https://secure-web.cisco.com/1LPZs4_m-Sjb7J2OF7hSci9uIIDVRJ8EVLBRY5CDKrIIZJcqZhLRy9txHMsJSf3DZNBBjTnO_yfRvSBnhX3IO-f09R9EaqerV4QjLjvGXOGu6oKf4paevsbGSTPv8mt-iHp2u9hxbkOyBarn1-t2ZgZF10KG11gkBQzvPhQnZaiDKZ4mnEcyBW0wQ6oR4hl11MLnN_rFOa269LUWu4C7tn6kiKGi5x4bs0z2cIW0N3s4s6nGkaoSty1Rw_8kQt1c8QyARYiLejJ_akIGtJmb-U0IMIw9JZKsideOakLD1sbW0cUR8D_VRD37mCqApuOCs/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FOncoSimulR%2F > > > https://secure-web.cisco.com/1TRr0mW7EHxnAYu4mZ5EPOhrFQVMMYiQUcymMf8unAW28HCPCv37EpvgSaY-Bd4kEvhtgBxJTfZONOY7Jyo7VC8Ijr2SvX_kRsJx_JPTrv9pyy_KwACIkqHp7L-Ac_4-NCcPAiGt7ImmrJIYoIQaTRl1eHmtRhql169MLnuiG1nzuOw_3-xczfDnIfQ-pC_Ai0NeZpjiHMgxuG9VGKTdi3M1ycqUx7NowAZf9AzoHKN_l5sIZA1TG4hNX217UAzQbJrT3Q1hXB80USxwvXYXvDWUoHaMp8zgmbEnHUIxbqYwO6Wfm6yaIGjlMBTffuU9H/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2FAgiMicroRna%2F > > > https://secure-web.cisco.com/1o8SgTdbVVNhIQs7ivAccToqJB9V7H-m1eqm66Y_pd5WfYet1zq5M62Lt4ZSTpKgVvh_2jGS5BBMPfJATxys4HRK9_-Ee_IpWOiuKr1Jn9z4PBWtVN-Yl20WZI-AY1CITPqpUjZDR18kp1lZCa2lK32fCh4t2RIpcy4hFKBXhlgvV6tt08RCLN4h8SMo8BhBbY10wxyxiDzrylI7fqx93HNWO-UvbTqhuE9gnRx3DLS0ro-aZhWkLwTsAdG-GvMwhbFqqCUW6zzXY_i6kE0uAT9GD5wKNEgIjAPjLl9KWou5vQ5rq6kt7bj3e-m0NKPEC/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2Fggcyto%2F > > > https://secure-web.cisco.com/1Ftx9oH59Y_JxkuehpZFkdhFER7ELXhXyMw0uaFIOPZwX0gHe1RWKDg2vAvmhO0tfONpdhIwpZm3TuKSXjxgho07TtSBmd4ZeOWOCKP6ROUEWTMfrhv1T6cLUIZVkhyaw2uRL3FDLC6jpvrXbkLcbjiNOlEvdxlPlz2fkODOPfgrJlqtj-aLRu3B2qz7kYI5tgsZ2VW6jC9iTBmrLmjf6IozEfT2zXpDESMZhbYxDYKzvHpNYREJsvENg5DLTeGrc1xghizQs1lb0pvmBvm24uGI0LIsM-6PHEqGyFlUnmgWtJY7Ql4_FiFO8-7YpxC8V/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2Fheatmaps%2F > > > https://secure-web.cisco.com/1afzI3GqGX-mHX4DDarX2jd2AktznzSU20ieI1-qks8kUqPF-Yu3O0fIUwToXvz7VWZru6pRekTa-2QkCAM2CkRVAMEPrFzLR9DPblCGWSFz1LcGCMF3SOkk_3g4e7ACokDHq_zH6tdG-n2tBMTPqdXepqt-QpZ9G5a4Q_kbjlwZFPV5wcKxAPuarJqUWszExfP-Tor9VKSNxm35MEIsany-KZvlcRfb206YG_-XXO1b1PeTScWb29izYpeZVEDUAEDjVqTAQ9Bb3fPX-VM-SDscUcvUdNzvVG4VCMk_AqXOXRdGbdVGHrzT85H0xkS4I/https%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2Fyarn%2F > > > This has been the case for at least a few days (weeks?). I can see no > obvious pattern, nor what could maintainers do to fix this. > > > Best, > > > R. > > -- > Ramon Diaz-Uriarte > Department of Biochemistry, Lab B-25 > Facultad de Medicina > Universidad Aut�noma de Madrid > Arzobispo Morcillo, 4 > 28029 Madrid > Spain > > Phone: +34-91-497-2412 > > Email: rdia...@gmail.com >ramon.d...@iib.uam.es > > > https://secure-web.cisco.com/1wIPeTMOPJZXqSNBoUPN4Q1VFwXVN8Am743dcl5De28eXZhqi_DzJsfc3tB9H-n-9yHJH9oshq-it3k_9YDzoWOtthu3YQoNrIIAFrB9fxHbXMzQlc6JgaYBhIHS2qQuy011HTR2zn64IsLs0c8rkuI6w5d4H446acH1aIzYiY4Yck_YGle7L0iuD3NQhjt5eQrzXbeJdhK8tG-rbC1UMzWbf-MFONXLKzvy_5hiX7iI25DlxMq3bffT1WFBvPVMnV9MR3_J6QV8_Td-omP6uJU9f_n5_Rz1NOLK0fRHebhdnri0
[Bioc-devel] riesling1: some package that install, build, check, and build bin OK, shown in red
Dear All, In BioC 3.14, with riesling1, some packages that are shown as OK in Install, Build, Check, and Build bin, show, however a red dot, and have no zip. Some examples are (the first one I maintain; the rest I just picked randomly): https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/ https://bioconductor.org/checkResults/devel/bioc-LATEST/AgiMicroRna/ https://bioconductor.org/checkResults/devel/bioc-LATEST/ggcyto/ https://bioconductor.org/checkResults/devel/bioc-LATEST/heatmaps/ https://bioconductor.org/checkResults/devel/bioc-LATEST/yarn/ This has been the case for at least a few days (weeks?). I can see no obvious pattern, nor what could maintainers do to fix this. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es https://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Question on copyright in Bioc vignette
Hi Fabricio,
Creative Commons has detailed instructions on how to apply the licenses:
http://creativecommons.org/licenses/by-sa/4.0/
I'd rather add a section at the beginning of the document, not at
the bottom. For instance, in Rnw documents, right after \tableofcontents I
add
\section*{License and copyright}\label{license}
This work is Copyright, \copyright, [year] [Name], and is licensed under a
\textbf{Creative Commons
} Attribution-ShareAlike 4.0 International License:
\Burl{http://creativecommons.org/licenses/by-sa/4.0/}.
\centerline \ccbysa
[Replace the license with the appropriate license and link]
Before all of that, though, you probably want to think carefully about the
license:
https://creativecommons.org/faq/#what-things-should-i-think-about-before-i-apply-a-creative-commons-license
(and this flowchart,
http://creativecommons.org.au/content/licensing-flowchart.pdf, I find very
helpful).
Best,
R.
P.S. I am dealing with the "how do I mention a CC-BY
license". Specifically, I am not addressing the "Does anyone know if
including the same figure in the vignette and in the paper would result in
copyright issues with the journal?". I am not a lawyer, and I've never seen
this, but I can imagine a journal could ask you to produce a figure
*specifically* for the paper, and then ask you to sign a copyright transfer
of the figure, and the rest of the paper, to the journal. I am not sure if
having the figure in the vignette under the CC license would help
here. Though this scenario, I guess, would be unlikely if you publish the
paper under an open access license. But, again, I am not a lawyer.
On Thu, 01-July-2021, at 19:42:28, Fabricio de Almeida
wrote:
> Hi, Laurent.
>
> Thank you for your suggestion. How would you mention that the vignette is
> licensed under CC-BY? A section named "License" at the bottom of the vignette?
>
> Best,
>
>
> =
>
>
> Fabrício de Almeida Silva
>
> Undergraduate degree in Biological Sciences (UENF)
>
> MSc. candidate in Plant Biotechnology (PGBV/UENF - RJ/Brazil)
>
> Laboratório de Química e Função de Proteínas e Peptídeos (LQFPP/CBB/UENF -
> RJ/Brazil)
>
> Lattes CNPq: http://lattes.cnpq.br/3119358824056108
>
> Personal website: https://almeidasilvaf.github.io/home/
>
>
> De: Laurent Gatto
> Enviado: quinta-feira, 1 de julho de 2021 12:32
> Para: Fabricio de Almeida ;
> bioc-devel@r-project.org
> Assunto: Re: Question on copyright in Bioc vignette
>
> Dear Fabrício,
>
> As far as I know, there's no explicit license on the documentation of a
> package, and I'm not sure the the package/software licence applies to
> documentation. I would explicitly mention that the figure (and possibly the
> vignette) is released under a CC-BY (or any alternative) to be on the safe
> side. If I had more time on my hands, I would probably add a CC-BY statement
> in each of my vignettes.
>
> I recently wanted to re-use a figure from another vignette and was able with
> the help of Hervé the track the original author and asked directly (on
> twitter) for permission to re-use it (with credit). A licence would make that
> straightforward.
>
> Best wishes,
>
> Laurent
>
>
> From: Bioc-devel on behalf of Fabricio de
> Almeida
> Sent: 01 July 2021 19:20
> To: bioc-devel@r-project.org
> Subject: [Bioc-devel] Question on copyright in Bioc vignette
>
> Hi, all.
>
> I am writing a vignette for a package I plan to submit next week, and I
> would like to include a figure explaining the package's
> algorithm. However, I would also like to include this figure in the paper
> that describes the package. Does anyone know if including the same figure
> in the vignette and in the paper would result in copyright issues with
> the journal?
>
> Sincerely,
>
>
> =
>
>
> Fabr�cio de Almeida Silva
>
> Undergraduate degree in Biological Sciences (UENF)
>
> MSc. candidate in Plant Biotechnology (PGBV/UENF - RJ/Brazil)
>
> Laborat�rio de Qu�mica e Fun��o de Prote�nas e Pept�deos (LQFPP/CBB/UENF -
> RJ/Brazil)
>
> Lattes CNPq: http://lattes.cnpq.br/3119358824056108
>
> Personal website: https://almeidasilvaf.github.io/home/
>
>
> [[alternative HTML version deleted]]
>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
https://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Install and check error in Windows without any relevant message
Hi Hervé,
Thanks! I'll keep my fingers crossed :-)
Best,
R.
On Wed, 12-May-2021, at 04:05:05, Hervé Pagès
wrote:
> Hi Ramon,
>
> This looks like a communication problem between riesling1 and
> nebbiolo1. Hopefully this is something transient. Fingers crossed!
>
> Cheers,
> H.
>
> On 11/05/2021 16:38, Ramon Diaz-Uriarte wrote:
>> To partially answer myself, on looking more carefully, the INSTALL problem
>> seems to happen in the call to curl.exe (i.e., not in the R package
>> installation itself per se). It seems this failed
>> C:\cygwin\bin\curl.exe -O
>> http://155.52.207.165/BBS/3.13/bioc/src/contrib/OncoSimulR_2.99.94.tar.gz
>> even if the tar.gz is actually there. Can I assume this is probably a
>> transient error?
>> And if I understand correctly the CHECK error ("Installation failed.
>> See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00install.out' for
>> details") it can also be traced to a curl problem?
>> Best,
>> On Tue, 11-May-2021, at 20:15:24, Ramon Diaz-Uriarte
>> wrote:
>>> Dear All,
>>>
>>> I package I maintain (OncoSimulR), which has not experienced any changes in
>>> the last week, has failed Install and Check (but not Build or Build bin) on
>>> Windows
>>> (https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-install.html
>>> https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-checksrc.html
>>> ).
>>>
>>> However, I do not know what to do given the error output. For Install the
>>> message is
>>>
>>> curl: (52) Empty reply from server
>>>
>>>
>>> And for Check is just
>>>
>>> * checking whether package 'OncoSimulR' can be installed ... ERROR
>>> Installation failed.
>>> See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00install.out' for
>>> details.
>>> * DONE
>>>
>>> Status: 1 ERROR
>>> See
>>>'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00check.log'
>>> for details.
>>>
>>> curl: (52) Empty reply from server
>>>
>>>
>>> I do not use curl in the code. Is this a problem fetching dependencies or a
>>> problem caused by a package I depend on?
>>>
>>>
>>> Thanks,
>>>
>>>
>>> R.
>>
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
https://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Install and check error in Windows without any relevant message
To partially answer myself, on looking more carefully, the INSTALL problem
seems to happen in the call to curl.exe (i.e., not in the R package
installation itself per se). It seems this failed
C:\cygwin\bin\curl.exe -O
http://155.52.207.165/BBS/3.13/bioc/src/contrib/OncoSimulR_2.99.94.tar.gz
even if the tar.gz is actually there. Can I assume this is probably a
transient error?
And if I understand correctly the CHECK error ("Installation failed.
See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00install.out' for
details") it can also be traced to a curl problem?
Best,
On Tue, 11-May-2021, at 20:15:24, Ramon Diaz-Uriarte wrote:
> Dear All,
>
> I package I maintain (OncoSimulR), which has not experienced any changes in
> the last week, has failed Install and Check (but not Build or Build bin) on
> Windows
> (https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-install.html
> https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-checksrc.html
> ).
>
> However, I do not know what to do given the error output. For Install the
> message is
>
> curl: (52) Empty reply from server
>
>
> And for Check is just
>
> * checking whether package 'OncoSimulR' can be installed ... ERROR
> Installation failed.
> See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00install.out' for
> details.
> * DONE
>
> Status: 1 ERROR
> See
> 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00check.log'
> for details.
>
> curl: (52) Empty reply from server
>
>
> I do not use curl in the code. Is this a problem fetching dependencies or a
> problem caused by a package I depend on?
>
>
> Thanks,
>
>
> R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
https://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] Install and check error in Windows without any relevant message
Dear All, I package I maintain (OncoSimulR), which has not experienced any changes in the last week, has failed Install and Check (but not Build or Build bin) on Windows (https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-install.html https://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/riesling1-checksrc.html ). However, I do not know what to do given the error output. For Install the message is curl: (52) Empty reply from server And for Check is just * checking whether package 'OncoSimulR' can be installed ... ERROR Installation failed. See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00install.out' for details. * DONE Status: 1 ERROR See 'D:/biocbuild/bbs-3.13-bioc/meat/OncoSimulR.Rcheck/00check.log' for details. curl: (52) Empty reply from server I do not use curl in the code. Is this a problem fetching dependencies or a problem caused by a package I depend on? Thanks, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es https://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] package that will not build under Windows with Rtools35 (but works with Rtools40)
Dear All, (Follow up to https://stat.ethz.ch/pipermail/bioc-devel/2019-May/015151.html) The newest version of a package we develop, OncoSimulR[1] cannot be built with Rtools35, the current toolchain[2], because of a known problem where compilation and linking fail[3]. However, we can build the package with Rtools40, and that produces a binary zip file that works with current R-3.6.0, R-3.6.0 patched, and R-devel. Is there any way to make the new functionality available through BioC in all the platforms? (I understand the answer is probably "no", since testing under Windows would not be possible with the current Rtools35 toolchain). Alternatively, is it possible to have some platforms use one code base or branch in a repo, and another platform (Windows) use a different code base/branch (i.e., use a code base without the new functionality so that it can build and check OK with Rtools 35)? Of course, any other suggestions welcome. Thanks, R. [1] https://bioconductor.org/packages/release/bioc/html/OncoSimulR.html https://github.com/rdiaz02/OncoSimul/tree/freq-dep-fitness [2] https://cran.r-project.org/bin/windows/Rtools/ [3] The "too many sections" error or the linker never finishing. E.g., https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/ -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] use -Wa, -mbig-obj -O3 when building package under Windows
Dear Kasper, Thank you very much. Using what you do in affxparser I can have the -O settings at will. (It turns out that did not solve the "too many sections" problem though, as now the linker never exists; but that is a different story ---I am currently trying to see if I can get it to work with Rtools 40). Thanks again, R. On Fri, 24-May-2019, at 16:31:31, Kasper Daniel Hansen wrote: > [ This is a crazy bug where you have to increase optimization. ] > > I some to add here. I am involved in at least two packages which requires > overriding the optimization switch to downgrade optimization. You have an > additional problem where you need to add additional flags. > > The solution in affxparser (see the source) is a custom compiler call where > we place -O0 before the system/package compiler flags. This is not a great > solution as it assumes that the compiler knows about -O notation (which is > true for GCC but not a true assumption everywhere). > > In Rgraphviz I have the same problem (but not solved yet because of ... > time). The issue here is that recent GCCs (v8 and higher) cannot be used > with -O3 but needs -O2. I have started to think about a better solution > than affxparser, to be used by the community, but have been a bit stumped. > Preferably I would like to use autoconf macro for detecting GCC, but when > we compile a package we are using the compiler encoded in R (aka $CC). So > somehow I want to run autoconf "detect which compiler is used" but for a > specific compiler. This is probably possible, but I don't know how right > now. > > Then, conditional on GCC I plan to do a regex which replaces -O3 with -O2. > This is not perfect either because the different -O3 optimizations can be > supplied as individual flags, and I don't know which flag it is which > breaks GCC. But it is must closer to the right solution. I don't know if > regex/sed'ing is better than overriding by changing the order as in > affxparser, but having the ability to do a conditional in Makevars would be > good. Of course, the autoconf route does not address Windows, but I think > we can assume / count on the fact that the RTools pipeline is used (aka, it > is always GCC). > > I would be happy to communicate more on this, to get this sorted out. It > has been a todo list item for me, for a while, and I should really try to > resolve it. > > But for a quick fix, look at affxparser. > > Best, > Kasper > > On Fri, May 24, 2019 at 10:16 AM Ramon Diaz-Uriarte > wrote: > >> >> Dear All, >> >> For a package we develop, OncoSimulR >> (https://bioconductor.org/packages/release/bioc/html/OncoSimulR.html), we >> have added new functionality >> (https://github.com/rdiaz02/OncoSimul/tree/freq-dep-fitness) that uses the >> ExprTk library[1] for parsing and evaluation of mathematical >> expressions. This works fine under Linux. But it is known[2] that ExprTk >> can fail when using MinGW with the "too many sections" error. >> >> >> A solution that has been suggested is to use -Wa,-mbig-obj with -O3 [3]. >> But I am unable to have R compile the package with -O3; -O3 is never >> placed at the right of the default -O2 no matter what I set in >> Makevars.win[4]. >> >> >> >> Any suggestions? >> >> Thanks, >> >> >> R. >> >> >> >> [1] http://www.partow.net/programming/exprtk/index.html >> [2] https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/ >> . >> [3] https://github.com/MrKepzie/Natron/blob/master/Engine/ExprTk.cpp >> "// exprtk requires -Wa,-mbig-obj on mingw, but there is a bug that >> prevents linking if not using -O3" >> >> See also, for example, >> https://discourse.mc-stan.org/t/too-many-sections/6261 >> >> [4] >> >> https://stackoverflow.com/questions/23414448/r-makevars-file-to-overwrite-r-cmds-default-g-options >> >> Our package has >> >> CXX_STD = CXX11 >> >> >> And I've tried: >> >> >> ## To the left of -O2 >> PKG_CXXFLAGS = -Wa,-mbig-obj -O3 >> >> ## To the left of -O2 >> PKG_CXXFLAGS += -Wa,-mbig-obj -O3 >> >> >> ## Also to the left of -O2 >> PKG_CPPFLAGS = -Wa,-mbig-obj -O3 >> >> ## Also to the left of -O2 >> PKG_CPPFLAGS += -Wa,-mbig-obj -O3 >> >> ## Ignored >> PKG_CXX11FLAGS = -Wa,-mbig-obj -O3 >> ## Ignored >> PKG_CXX11FLAGS += -Wa,-mbig-obj -O3 >> >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medic
[Bioc-devel] use -Wa, -mbig-obj -O3 when building package under Windows
Dear All, For a package we develop, OncoSimulR (https://bioconductor.org/packages/release/bioc/html/OncoSimulR.html), we have added new functionality (https://github.com/rdiaz02/OncoSimul/tree/freq-dep-fitness) that uses the ExprTk library[1] for parsing and evaluation of mathematical expressions. This works fine under Linux. But it is known[2] that ExprTk can fail when using MinGW with the "too many sections" error. A solution that has been suggested is to use -Wa,-mbig-obj with -O3 [3]. But I am unable to have R compile the package with -O3; -O3 is never placed at the right of the default -O2 no matter what I set in Makevars.win[4]. Any suggestions? Thanks, R. [1] http://www.partow.net/programming/exprtk/index.html [2] https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/. [3] https://github.com/MrKepzie/Natron/blob/master/Engine/ExprTk.cpp "// exprtk requires -Wa,-mbig-obj on mingw, but there is a bug that prevents linking if not using -O3" See also, for example, https://discourse.mc-stan.org/t/too-many-sections/6261 [4] https://stackoverflow.com/questions/23414448/r-makevars-file-to-overwrite-r-cmds-default-g-options Our package has CXX_STD = CXX11 And I've tried: ## To the left of -O2 PKG_CXXFLAGS = -Wa,-mbig-obj -O3 ## To the left of -O2 PKG_CXXFLAGS += -Wa,-mbig-obj -O3 ## Also to the left of -O2 PKG_CPPFLAGS = -Wa,-mbig-obj -O3 ## Also to the left of -O2 PKG_CPPFLAGS += -Wa,-mbig-obj -O3 ## Ignored PKG_CXX11FLAGS = -Wa,-mbig-obj -O3 ## Ignored PKG_CXX11FLAGS += -Wa,-mbig-obj -O3 -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] build/check reports and package version available for updated package
Hi Herve, Thanks a lot for the explanation; mystery solved. And yes, I can now see the updated report. Best, R. On Sat, 09-February-2019, at 10:54:40, Pages, Herve wrote: > Hi Ramon, > > We run the software builds every night and normally the build report > gets updated every morning (for the people on the East Coast). However > sometimes things don't work as expected. This time the builds went fine > but the script that updates the report failed so that's why we still see > the report from the day before. However, it seems that OncoSimulR 2.13.1 > passed 'R CMD check' on all platforms and propagated so this is why you > see it on the package landing page. > > I addressed the issue with the script so hopefully the report will get > updated today around 10 am EST. We should see OncoSimulR 2.13.1 on this > new report. > > Best, > > H. > > On 2/9/19 01:13, Ramon Diaz-Uriarte wrote: >> Dear All, >> >> For the development version of a package, I thought that a new version of a >> package (a new version of the archive) was only made available if and when >> the build/check reports had been passed (for the corresponding OS). But now >> I think I am wrong. >> >> >> For a package I maintain, OncoSimulR, I am seeing package archives for the >> new version (2.13.1) that correspond to the changes I pushed a couple of >> days ago, on 2019-02-07 >> (https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_packages_3.9_bioc_html_OncoSimulR.html=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=O0cn-X5Sr3_HhPWuSmTxh06I6kzACAP-AsUKsDNCnEU=y8Ni6d5RDqXiSzMWYbsOa6z3CQCHAnB7ViGb_iYe70Y=); >> but the >> build report >> (https://urldefense.proofpoint.com/v2/url?u=https-3A__bioconductor.org_checkResults_3.9_bioc-2DLATEST_OncoSimulR_=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=O0cn-X5Sr3_HhPWuSmTxh06I6kzACAP-AsUKsDNCnEU=rYQOEwOloojsIaUf3cwDap2VkbgGYyzQjuXOcHMFVmI=) >> is >> still showing the build/check from the previous version (2.13.0), which was >> the one that existed at the time of the snapshot date (2019-02-06 17:01:03 >> -0500) of the report. >> >> >> Does this mean that a build bin was executed (I presume successfully) >> shortly after I pushed changes? I think it must, given the "Packaged" stamp >> in the DESCRIPTION file of the three compressed files (which shows >> "2019-02-08 01:19:24 UTC; biocbuild" and similar strings). What about the >> install and check tests? >> >> >> Sorry if this has been explained before. I've looked around but could not >> find any info about it. >> >> >> Thanks, >> >> >> R. >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__ligarto.org_rdiaz=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=O0cn-X5Sr3_HhPWuSmTxh06I6kzACAP-AsUKsDNCnEU=lwENxLhyf-d-fQHkWDDmw2N9LcJ9lgfIY10F4SMCJx8= >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel=DwIDaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=O0cn-X5Sr3_HhPWuSmTxh06I6kzACAP-AsUKsDNCnEU=BpOP1oelpZxdAeeLjqgmTXtZNUxHirmC3nDujcXKJeo= -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] build/check reports and package version available for updated package
Dear All, For the development version of a package, I thought that a new version of a package (a new version of the archive) was only made available if and when the build/check reports had been passed (for the corresponding OS). But now I think I am wrong. For a package I maintain, OncoSimulR, I am seeing package archives for the new version (2.13.1) that correspond to the changes I pushed a couple of days ago, on 2019-02-07 (https://bioconductor.org/packages/3.9/bioc/html/OncoSimulR.html); but the build report (https://bioconductor.org/checkResults/3.9/bioc-LATEST/OncoSimulR/) is still showing the build/check from the previous version (2.13.0), which was the one that existed at the time of the snapshot date (2019-02-06 17:01:03 -0500) of the report. Does this mean that a build bin was executed (I presume successfully) shortly after I pushed changes? I think it must, given the "Packaged" stamp in the DESCRIPTION file of the three compressed files (which shows "2019-02-08 01:19:24 UTC; biocbuild" and similar strings). What about the install and check tests? Sorry if this has been explained before. I've looked around but could not find any info about it. Thanks, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
On Wed, 18-April-2018, at 21:09:32, Martin Morgan
<martin.mor...@roswellpark.org> wrote:
> On 04/18/2018 02:45 PM, Vincent Carey wrote:
>>
>>
>> On Mon, Apr 9, 2018 at 11:23 AM, Martin Morgan
>> <martin.mor...@roswellpark.org <mailto:martin.mor...@roswellpark.org>>
>> wrote:
>>
>>
>>
>> On 04/09/2018 10:51 AM, Ramon Diaz-Uriarte wrote:
>>
>>
>> Dear Martin,
>>
>> On Fri, 06-April-2018, at 18:59:00, Martin Morgan
>> <martin.mor...@roswellpark.org
>> <mailto:martin.mor...@roswellpark.org>> wrote:
>>
>> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>>
>> I have recently faced a similar warning.
>> This is when a link to a help page of another package is
>> broken (there is
>> not such help page). Although those could be false
>> positives:
>> mclapply help page does exists in parallel package.
>> as.MAList does exists in devel limma
>>
>>
>> when \link-ing to another package, from RShowDoc("R-exts")
>> section 2.5
>> the [] has to name the html help page, not the name of the
>> function. For
>> instance, `mclapply` is documented on a man page called
>> mcdummies.Rd
>> (!), so '\link[parallel:mcdummies]{nearest} would presumably not
>>
>>
>> I am confused here: as far as I can tell, there is an
>> mclapply.html file:
>>
>>
>> http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html
>>
>> <http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html>
>>
>> In addition, when I use the \link[parallel:mcdummies] I get a
>> warning when
>> testing under Linux.
>>
>>
>> yeah, this is a pretty good one. If you look at
>>
>> https://github.com/wch/r-source/tree/trunk/src/library/parallel/man
>> <https://github.com/wch/r-source/tree/trunk/src/library/parallel/man>
>>
>> you'll see that there are different man pages for different
>> operating systems. On windows there is mcdummies, on unix mclapply &
>> friends. This seems like a bad idea (users comparing notes to work
>> through a problem get different help pages!). I don't really know
>> how to link explicitly to these in a conditional manner.
>>
>>
>> Does this mean that to cross-reference to MArrayLM-class, I need to find
>> limma source and
>> determine that the topic is covered in marraylm.Rd and use
>> \link[limma:marraylm]{MArrayLM-class} for
>> the cross-reference? I don't see how this is good -- are the page names
>> programmatically accessible
>> to developers who want to cross-reference? here's the grep result:
>>
>> marraylm.Rd:\alias{MArrayLM-class}
>
> I agree that this is a bad idea.
>
> I think the first solution is not to use \link[pkg]{foo} when it is not
> needed, which Writing R Extensions
> (https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Cross_002dreferences)
>
> says
>
>"These are rarely needed, perhaps to refer to not-yet-installed
> packages (but there the HTML help system will resolve the link at run
> time) or in the normally undesirable event that more than one package
> offers help on a topic"
>
> Packages you depend / import and even suggest will be installed by the
> build system, so the only need is when two or more packages define the
> same topic.
>
> But even then, when faced with a WARNING, and even Bioc core team
> members or reviewers for new packages hassling you about correcting
> WARNINGs, I personally would trade off sanity for perfection and stick
> with \link[limma]{MArrayLM-class} -- there is a WARNING, but the warning
> says that it's going to treat MArrayLM-class as a topic (alias) and
> it'll get resolved correctly.
>
Martin, thanks for the detailed explanation (and the choice of sanity over
perfection :-) ).
Best,
R.
> Also, for what it's worth, the opinion expressed in
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Cross_002dreferences
>
> is that the fact that these WARNINGs are often Windows-specific is more
> likely that the linux check is wrong (i.e., the WARNING should also be
> generated there). I will try to investigate that further.
>
> Martin
>
>
>>
>>
>> An
Re: [R-pkg-devel] Rd files: using \link[pkg]{foo} when file names differ between OSs
Dear Duncan,
On Mon, 16-April-2018, at 17:52:10, Duncan Murdoch <murdoch.dun...@gmail.com>
wrote:
> On 16/04/2018 11:35 AM, Ramon Diaz-Uriarte wrote:
>> Dear All,
>>
>> Two recent threads in the bioconductor devel mailing list
>> (https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html and
>> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013259.html) are
>> related to packages that have different names of html files in different
>> operating systems.
>>
>> For example, parallel has a file called mclapply in Linux. So using, from
>> the Rd file of another package, \link[parallel]{mclapply} works fine under
>> Linux, but does not under Windows, because there is no mclapply.html file
>> in Windows (there is a mcdummies file).
>>
>>
>> Is there any recommended way to proceed in these cases?
>>
>>
>> Yes, section 2.5 of Writing R Extensions indicates that \link[pkg]{foo}
>> and \link[pkg:bar]{foo} are rarely needed; so the simplest way to proceed
>> would be to avoid \link[pkg]{foo} and \link[pkg:bar]{foo}. I am asking for
>> the cases where, as noted in 2.5, "more than one package offers help on a
>> topic".
>
> You could make the links conditional on the OS. For example,
>
> #ifdef windows
> See \link[parallel]{mcdummies}.
> #endif
> #ifdef unix
> See \link[parallel]{mclapply}.
> #endif
Thanks. I wasn't aware that was possible.
>
> The other possibility (useful if there are major differences between the
> platforms) is to have two copies of the help file, one in man/unix, one
> in man/windows, but that doesn't seem appropriate from your description.
I think the previous one is better (actually, for my specific cases right
now, I was able to solve the problem using \link{foo} since only one
packages offers help on the topic I link to).
Best,
R.
>
> Duncan Murdoch
>>
>>
>> Thanks,
>>
>>
>> R.
>>
>> --
>> Ramon Diaz-Uriarte
>> Department of Biochemistry, Lab B-25
>> Facultad de Medicina
>> Universidad Autónoma de Madrid
>> Arzobispo Morcillo, 4
>> 28029 Madrid
>> Spain
>>
>> Phone: +34-91-497-2412
>>
>> Email: rdia...@gmail.com
>> ramon.d...@iib.uam.es
>>
>> http://ligarto.org/rdiaz
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] Windows
And I have now asked this in R-pkg-devel
(https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002617.html), as
suggested by Martin Maechler
(https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013169.html) in the
thread linked by Lori.
But if you can use \link{foo} (instead of \link[pkg]{foo} and
\link[pkg:bar]{foo}), as also suggested by Håkon Tjeldnes, then you should
have no problems.
Best,
R.
On Mon, 16-April-2018, at 13:16:54, Shepherd, Lori
<lori.sheph...@roswellpark.org> wrote:
> This was also discussed in this thread a few weeks ago
>
> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html
>
>
>
> Lori Shepherd
>
> Bioconductor Core Team
>
> Roswell Park Cancer Institute
>
> Department of Biostatistics & Bioinformatics
>
> Elm & Carlton Streets
>
> Buffalo, New York 14263
>
>
> From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Mike Smith
> <grimbo...@gmail.com>
> Sent: Monday, April 16, 2018 6:13:38 AM
> To: Rainer Johannes; bioc-devel
> Subject: Re: [Bioc-devel] Windows on Tokay2>
>
> Martin mentioned that he changed the wording in
> https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
> , so more recently than your version of R-devel.
>
> Mike
>
> On 16 April 2018 at 11:57, Rainer Johannes <johannes.rai...@eurac.edu>
> wrote:
>
>> Thanks Mike,
>>
>> I somehow missed the discussion you mentioned. I would really not like to
>> include the name of the Rd file I want to link to. The *default* way that
>> works on Linux and macOS should also work on Windows - otherwise what's the
>> matter of the alias? Interestingly, on my Windows test machine (Windows 7)
>> I don't get these warnings (R-devel from 2018-01-07 r74091).
>>
>> jo
>>
>> > On 16 Apr 2018, at 10:49, Mike Smith <grimbo...@gmail.com> wrote:
>> >
>> > Hi Johannes,
>> >
>> > xcms is certainly not alone with the warning, and it was discussed in
>> https://stat.ethz.ch/pipermail/bioc-devel/2018-April/013156.html
>> >
>> > I think you should be able to get round it by including the name of Rd
>> file you're linking to e.g.
>> \code{\link[MSnbase:pickpeaks-method]{pickPeaks}}
>> (I haven't actually tested this though).
>> >
>> > Mike
>> >
>> > On 16 April 2018 at 09:06, Rainer Johannes <johannes.rai...@eurac.edu>
>> wrote:
>> > Dear all,
>> >
>> > we're experiencing WARNINGS in xcms on Tokay2 that are all related to
>> links in Rd files to functions and methods in other packages.
>> > Example:
>> > we have \code{\link[MSnbase]{pickPeaks}} in
>> XCMSnExp-inherited-methods.Rd that links to the method in MSnbase, that
>> works nicely on Linux and macOS build machines, but on tokay2 we get:
>> >
>> > Rd warning: C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmpw7qeJw/R.
>> INSTALL1e704df56ca9/xcms/man/XCMSnExp-inherited-methods.Rd:59: file link
>> 'pickPeaks' in package 'MSnbase' does not exist and so has been treated as
>> a topic
>> >
>> > is there any other solution to removing all links to external packages?
>> >
>> > thanks, jo
>> >
>> > ___
>> > Bioc-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> >
>>
>>
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>
> 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
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
Dear Martin,
On Mon, 09-April-2018, at 17:35:47, Martin Maechler
<maech...@stat.math.ethz.ch> wrote:
>>>>>> Ramon Diaz-Uriarte <rdia...@gmail.com>
>>>>>> on Mon, 9 Apr 2018 16:51:38 +0200 writes:
>
> > Dear Martin,
>
> > On Fri, 06-April-2018, at 18:59:00, Martin Morgan
> > <martin.mor...@roswellpark.org> wrote:
> >> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
> >>> I have recently faced a similar warning. This is when a
> >>> link to a help page of another package is broken (there
> >>> is not such help page). Although those could be false
> >>> positives: mclapply help page does exists in parallel
> >>> package. as.MAList does exists in devel limma
> >>
> >> when \link-ing to another package, from
> >> RShowDoc("R-exts") section 2.5 the [] has to name the
> >> html help page, not the name of the function. For
> >> instance, `mclapply` is documented on a man page called
> >> mcdummies.Rd (!), so '\link[parallel:mcdummies]{nearest}
> >> would presumably not
>
> > I am confused here: as far as I can tell, there is an
> > mclapply.html file:
>
> > http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html
>
> > In addition, when I use the \link[parallel:mcdummies] I
> > get a warning when testing under Linux.
>
>
> > On rereading section 2.5, I think \link[pkg]{foo} should
> > work too (if there is a foo.html file.)
>
> > Nevertheless, section 2.5 indicates that \link[pkg]{foo}
> > and \link[pkg:bar]{foo} are rarely needed, so I'll try to
> > remove them (except in those cases, covered in section
> > 2.5, where "more than one package offers help on a topic")
>
> Only on Windows, indeed,
> mclapply() is just a dummy function, calling lapply() IIRC.
>
> It is unfortunate that given the above you would be lead to use
> different \link{}s if you are on Windows than on non-Win...
>
> This would be a good question on the R-package-devel mailing
> list.
>
Done (https://stat.ethz.ch/pipermail/r-package-devel/2018q2/002617.html).
Thanks,
R.
> Martin
>
>
> >> generate the warning. Similarly
> >> \link[limma:asmalist]{as.MAList}.
> >>
> >> There are several things that still need exploration.
> >>
> >> - platform-specific (I have a vague understanding that
> >> Windows is special, but that might be outdated... [at
> >> least in this context...])
> >>
>
> > I am only getting the warnings under Windows (which lead
> > me to think it was windows misbehaving).
>
>
> >> - recent. I have to admit to changing the text of the
> >> warning with this commit
> >>
> >>
> >>
> https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
> >>
> >> but what I was intending to do was to change what it
> >> says, from the warning in release ('missing file link')
> >> to what it says, correctly, in devel 'file link ... does
> >> not exist and so has been treated as a topic'. The old
> >> text appears in release, and the new in devel, as
> >> anticipated. If I messed up somehow please let me
> >> know...
> >>
> >> - even with the warning, the link isn't broken in the
> >> dynamic help system (it might have been broken prior to
> >> my commit...).
>
> > OK, thanks.
>
> > Best,
>
>
> > R.
>
>
> >>
> >> Martin
> >>
> >>>
> >>> HTH
> >>>
> >>> On 6 April 2018 at 16:35, Vincent Carey
> >>> <st...@channing.harvard.edu> wrote:
> >>>
> >>>> ive seen this too apropos bigrquery on windows
> >>>>
> >>>> On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte
> >>>> <rdia...@gmail.com> wrote:
> >>>>
> >>>>>
> >>>>> Dear All,
> >>>>>
> >>>>> Two packages I maintain are showing, in Windows, a
> >>>>> warning during check with messages like
> >>>>>
> >>>>> Rd warning:
> >>>>>
> C:/Users/biocbuild/bbs-3.7-
Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
Dear Martin,
On Fri, 06-April-2018, at 18:59:00, Martin Morgan
<martin.mor...@roswellpark.org> wrote:
> On 04/06/2018 10:44 AM, Lluís Revilla wrote:
>> I have recently faced a similar warning.
>> This is when a link to a help page of another package is broken (there is
>> not such help page). Although those could be false positives:
>> mclapply help page does exists in parallel package.
>> as.MAList does exists in devel limma
>
> when \link-ing to another package, from RShowDoc("R-exts") section 2.5
> the [] has to name the html help page, not the name of the function. For
> instance, `mclapply` is documented on a man page called mcdummies.Rd
> (!), so '\link[parallel:mcdummies]{nearest} would presumably not
I am confused here: as far as I can tell, there is an mclapply.html file:
http://stat.ethz.ch/R-manual/R-devel/library/parallel/html/mclapply.html
In addition, when I use the \link[parallel:mcdummies] I get a warning when
testing under Linux.
On rereading section 2.5, I think \link[pkg]{foo} should work too (if there
is a foo.html file.)
Nevertheless, section 2.5 indicates that \link[pkg]{foo} and
\link[pkg:bar]{foo} are rarely needed, so I'll try to remove them (except
in those cases, covered in section 2.5, where "more than one package offers
help on a topic")
> generate the warning. Similarly \link[limma:asmalist]{as.MAList}.
>
> There are several things that still need exploration.
>
> - platform-specific (I have a vague understanding that Windows is
> special, but that might be outdated... [at least in this context...])
>
I am only getting the warnings under Windows (which lead me to think it was
windows misbehaving).
> - recent. I have to admit to changing the text of the warning with this
> commit
>
>
> https://github.com/wch/r-source/commit/cbd7ca1b1aedf0405e11ee2440fbde891cba524e
>
>but what I was intending to do was to change what it says, from the
> warning in release ('missing file link') to what it says, correctly, in
> devel 'file link ... does not exist and so has been treated as a topic'.
> The old text appears in release, and the new in devel, as anticipated.
> If I messed up somehow please let me know...
>
> - even with the warning, the link isn't broken in the dynamic help
> system (it might have been broken prior to my commit...).
OK, thanks.
Best,
R.
>
> Martin
>
>>
>> HTH
>>
>> On 6 April 2018 at 16:35, Vincent Carey <st...@channing.harvard.edu> wrote:
>>
>>> ive seen this too apropos bigrquery on windows
>>>
>>> On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte <rdia...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Dear All,
>>>>
>>>> Two packages I maintain are showing, in Windows, a warning during check
>>>> with messages like
>>>>
>>>> Rd warning:
>>>> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/
>>> OncoSimulR/man/oncoSimulIndiv.Rd:570:
>>>> file link 'mclapply' in package 'parallel' does not exist and so has been
>>>> treated as a topic
>>>>
>>>> or
>>>>
>>>> Rd warning:
>>>> C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.
>>> INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45:
>>>> file link 'as.MAList' in package 'limma' does not exist and so has been
>>>> treated as a topic
>>>>
>>>>
>>>>
>>>> that I cannot reproduce under Linux and that I think are false
>>>> positives. Is there a way to avoid this warning? As far as I can tell,
>>>> those links really exist.
>>>>
>>>> Best,
>>>>
>>>>
>>>> R.
>>>>
>>>> --
>>>> Ramon Diaz-Uriarte
>>>> Department of Biochemistry, Lab B-25
>>>> Facultad de Medicina
>>>> Universidad Autónoma de Madrid
>>>> Arzobispo Morcillo, 4
>>>> 28029 Madrid
>>>> Spain
>>>>
>>>> Phone: +34-91-497-2412
>>>>
>>>> Email: rdia...@gmail.com
>>>> ramon.d...@iib.uam.es
>>>>
>>>> http://ligarto.org/rdiaz
>>>>
>>>> ___
>>>> Bioc-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> Bioc-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>
>>
>> [[alternative HTML version deleted]]
>>
>> ___
>> Bioc-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>
>
>
> This email message may contain legally privileged and/or...{{dropped:2}}
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
Dear Lluis and Vincent, Thanks for confirming this in other packages. In the two examples shown, these must be false positives, as the links exist. But also the fact that the warnings only appear in Windows suggests a false positive: I do not understand how this warning would not be triggered in Linux and Mac if the links did not exist. Best, R. On Fri, 06-April-2018, at 16:44:42, Lluís Revilla <lluis.revi...@gmail.com> wrote: > I have recently faced a similar warning. > This is when a link to a help page of another package is broken (there is > not such help page). Although those could be false positives: > mclapply help page does exists in parallel package. > as.MAList does exists in devel limma > > HTH > > On 6 April 2018 at 16:35, Vincent Carey <st...@channing.harvard.edu> wrote: > >> ive seen this too apropos bigrquery on windows >> >> On Fri, Apr 6, 2018 at 10:22 AM Ramon Diaz-Uriarte <rdia...@gmail.com> >> wrote: >> >> > >> > Dear All, >> > >> > Two packages I maintain are showing, in Windows, a warning during check >> > with messages like >> > >> > Rd warning: >> > C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/ >> OncoSimulR/man/oncoSimulIndiv.Rd:570: >> > file link 'mclapply' in package 'parallel' does not exist and so has been >> > treated as a topic >> > >> > or >> > >> > Rd warning: >> > C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R. >> INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45: >> > file link 'as.MAList' in package 'limma' does not exist and so has been >> > treated as a topic >> > >> > >> > >> > that I cannot reproduce under Linux and that I think are false >> > positives. Is there a way to avoid this warning? As far as I can tell, >> > those links really exist. >> > >> > Best, >> > >> > >> > R. >> > >> > -- >> > Ramon Diaz-Uriarte >> > Department of Biochemistry, Lab B-25 >> > Facultad de Medicina >> > Universidad Autónoma de Madrid >> > Arzobispo Morcillo, 4 >> > 28029 Madrid >> > Spain >> > >> > Phone: +34-91-497-2412 >> > >> > Email: rdia...@gmail.com >> >ramon.d...@iib.uam.es >> > >> > http://ligarto.org/rdiaz >> > >> > ___ >> > Bioc-devel@r-project.org mailing list >> > https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > >> >> [[alternative HTML version deleted]] >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] BioC 3.7 Windows check warning "file link zz in package yy does not exist "
Dear All, Two packages I maintain are showing, in Windows, a warning during check with messages like Rd warning: C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/Rtmp21WlQD/R.INSTALL23343f935731/OncoSimulR/man/oncoSimulIndiv.Rd:570: file link 'mclapply' in package 'parallel' does not exist and so has been treated as a topic or Rd warning: C:/Users/biocbuild/bbs-3.7-bioc/tmpdir/RtmpQfQaA1/R.INSTALL1ec81d5b6233/ADaCGH2/man/inputToADaCGH.Rd:45: file link 'as.MAList' in package 'limma' does not exist and so has been treated as a topic that I cannot reproduce under Linux and that I think are false positives. Is there a way to avoid this warning? As far as I can tell, those links really exist. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.7: build failing on Mac (merida2) because Cairo not available
Dear Lori, Thanks for the update. Best, R. On Thu, 05-April-2018, at 14:48:09, Shepherd, Lori <lori.sheph...@roswellpark.org> wrote: > It doesn't look like the CAIRO mac binary is available yet for R 3.5 - as > soon as it becomes available we will update our systems. For now you can > ignore this ERROR. > > > > Lori Shepherd > > Bioconductor Core Team > > Roswell Park Cancer Institute > > Department of Biostatistics & Bioinformatics > > Elm & Carlton Streets > > Buffalo, New York 14263 > > ____ > From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Ramon > Diaz-Uriarte <rdia...@gmail.com> > Sent: Wednesday, April 4, 2018 11:20:27 AM > To: bioc-devel@ > Cc: ramon.d...@iib.uam.es > Subject: [Bioc-devel] BioC 3.7: build failing on Mac (merida2) because Cairo > not available > > Dear All, > > A package I maintain (ADaCGH2) is giving an error during build > (http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/merida2-buildsrc.html) > because Cairo is not available. A quick look at other packages that depend > on Cairo shows the same problem there. > > What should we do? > > > Best, > > > R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] BioC 3.7: build failing on Mac (merida2) because Cairo not available
Dear All, A package I maintain (ADaCGH2) is giving an error during build (http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/merida2-buildsrc.html) because Cairo is not available. A quick look at other packages that depend on Cairo shows the same problem there. What should we do? Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] EXTERNAL: BioC 3.6: timeouts on veracruz1 (OS X)
Dear Martin, On Fri, 13-October-2017, at 12:27:31, Martin Morgan <martin.mor...@roswellpark.org> wrote: > On 10/12/2017 07:08 AM, Ramon Diaz-Uriarte wrote: >> Dear All, >> >> I have noticed that on the latest build report, a package I maintain, >> OncoSimulR >> (http://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/veracruz1-buildsrc.html), > > I wonder if it is this issue > >https://github.com/Bioconductor/BiocParallel/issues/67 > > which would occur if your vignette has parallel code (using 'fork' > processed via parallel::mclapply or indirectly via > BiocParallel::MulticoreParam() / doParallel etc.) > Yes! I have both explicit calls to mclapply and implicit ones (functions that call functions that call mclapply) in the vignette. > If so then the best strategy is to wait for an upstream fix. > OK. Thank you. Best, R. > Martin > > >> has status timeout on veracruz1. Package building stalls during >> creation of the vignette (that is not happening in the malbec1 ---linux--- >> build). I have noticed that this same pattern (timeout with build stopped >> when >> creating the vignette in veracruz1 but not in malbec1) seems to affect >> other packages >> (http://bioconductor.org/checkResults/devel/bioc-LATEST/index.html#show=timeout). >> >> Is there anything we should do? Just looking at the log I do not know how >> to proceed. >> >> >> Thanks, >> >> >> R. >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > > 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. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Maintainers submit your SSH public keys
Dear Nitesh, Things are working, thanks. One minor suggestion: would it be worth pointing out (for example, in https://github.com/Bioconductor/bioc_git_transition ) that to clone with read/write permissions we might need to add the ssh key to the agent in the current session, specially if we use a key different from id_rsa? (This is covered, for instance, in https://help.github.com/articles/error-permission-denied-publickey/ ) Best, R. On Wed, 12-07-2017, at 15:29:11, Turaga, Nitesh <nitesh.tur...@roswellpark.org> wrote: > Hi Ramon, > > This is a good question. Your key will be processed every 24 hours. If you > have already submitted, then, you should be able to work through the > documentation provided > (https://github.com/Bioconductor/bioc_git_transition/tree/master/doc). > Working through the documentation to check everything is in order helps > everyone in the Bioconductor community too. > > Or a simple way to check is, make a change in your cloned package, ideally > it is a ³version bump² in the DESCRIPTION file. Then, try to git add ‹> > commit ‹> push the change up to the new git server. These steps are given > in our documentation, > > https://github.com/Bioconductor/bioc_git_transition/blob/master/doc/scenari > o-11-maintain-without-github.md#clone-and-setup-the-package-on-your-local-m > achine > > > https://github.com/Bioconductor/bioc_git_transition/blob/master/doc/scenari > o-11-maintain-without-github.md#make-and-commit-changes-to-your-local-repos > itory > > > We appreciate feedback on this. > > Best, > > Nitesh > > P.S We have already processed your previous submission. Don¹t worry, we > don¹t process duplicate submissions. > > >>Dear Nitesh, >> >>I just filled it up again, though I think I did fill up and hit >>send/submit >>a few days ago. Is there a way for me to confirm it has worked? >> >> >>Best, >> >> >>R. >> >> >> >>On Wed, 12-07-2017, at 14:50:14, Turaga, Nitesh >><nitesh.tur...@roswellpark.org> wrote: >>> Hi Maintainers, >>> >>> Please submit your (SSH public key or GitHub id) and SVN id in this >>>google >>> form https://goo.gl/forms/eg36vcBkIUjfZfLe2. It will only take a minute >>>or >>> less. >>> >>> This is a crucial step to the transition, which is going to happen soon. >>> You will be able to test/complain/learn about the new git server during >>> Bioc2017 (Boston - July 26th onwards), and will be good to go from the >>>day >>> of transition. It is critical for maintainers who are actively >>>maintaining >>> their package on Bioconductor. >>> >>> We have received very few SSH public keys so far from the 1300+ >>> maintainers in Bioconductor. >>> >>> >>> Best Regards, >>> >>> Nitesh >>> >>> >>> >>> >>> 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. >>> ___ >>> Bioc-devel@r-project.org mailing list >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >>-- >>Ramon Diaz-Uriarte >>Department of Biochemistry, Lab B-25 >>Facultad de Medicina >>Universidad Autónoma de Madrid >>Arzobispo Morcillo, 4 >>28029 Madrid >>Spain >> >>Phone: +34-91-497-2412 >> >>Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >>http://ligarto.org/rdiaz > > > > 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. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Hi Hervé, On Sat, 15-04-2017, at 05:36:35, Hervé Pagès <hpa...@fredhutch.org> wrote: > Hi Ramon, > > Good news: looks like a Cairo binary for R 3.4 showed up on CRAN > yesterday: > >https://cran.r-project.org/bin/macosx/el-capitan/contrib/3.4/ > > I installed it on veracruz2, and, according to the logs of the > current builds, ADaCGH2 built and checked successfully on this Great! > machine :-) If everything goes well, this should be reflected > in the next build report (Sat Apr 15). > > Thanks again for your patience, Thank you and Martin for looking into this and letting me know. Best, R. > > Cheers, > H. > > > On 04/08/2017 06:34 AM, Ramon Diaz-Uriarte wrote: >> >> Dear Martin, >> >> >> On Fri, 07-04-2017, at 12:55:55, Martin Morgan >> <martin.mor...@roswellpark.org> wrote: >>> On 04/07/2017 03:55 AM, Ramon Diaz-Uriarte wrote: >>>> >>>> Dear Martin and Valerie, >>>> >>>> >>>> I am not sure how to proceed here since the 14th is approaching and I still >>>> see this error (in both my package and at least one other package >>>> ---arrayQualityMetrics). >>>> >>>> >>>> I could comment out the plotting code for the vignette and examples when >>>> running on El Capitan. Is this a possible workaround that I should >>> >>> In general this is the wrong thing to do, since it enables shipping >>> broken code with no possibility of future fixes. Be patient. Martin >> >> Thanks for your answer. I'll be patient :-) >> >> (Just to clarify: I understand that what I was proposing was an ugly >> kludge; I think I have misunderstood the issue; apologies for the noise) >> >> Best, >> >> R. >> >>> >>>> implement? If this is reasonable, what is the recommended way to find out >>>> the code is running in El Capitan and not Mavericks? (For instance, can I >>>> tell from Sys.info()["sysname"]? --I do not have access to a Mac). >>>> >>>> >>>> Martin mentioned that the Cairo package requires a binary installation that >>>> is not yet available. Should I continue to wait? There is not a lot of >>>> margin for changing the code, uploading to BioC, waiting for the build, and >>>> making sure it works. What if it continues to fail on El Capitan by the >>>> 14th? >>>> >>>> >>>> >>>> Best, >>>> >>>> >>>> R. >>>> >>>> >>>> >>>> >>>> On Mon, 03-04-2017, at 18:34:26, Martin Morgan >>>> <martin.mor...@roswellpark.org> wrote: >>>>> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote: >>>>>> >>>>>> Dear All, >>>>>> >>>>>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a >>>>>> segfault that seems to happen when plotting (in a call to plotting that >>>>>> happens inside a mclapply) >>>>>> >>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ADaCGH2_veracruz2-2Dbuildsrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=67SOhhQ_xN5IxOZP7n-Vuvtn1Da8u3G6YqpEVI4fTsw=yu6OVUP4gT1jkj9xheyXRvn5-tHhTOM1X3QgpWRr4DE= >>>>>> >>>>>> >>>>>> these are some of the lines of the traceback: >>>>>> >>>>>> Traceback: >>>>>> 1: dev.hold() >>>>>> 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, >>>>>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, >>>>>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, >>>>>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, >>>>>> 77282738, 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, >>>>>> 107610854, 108945724, 120577571, 122947762.5, 124680401, 129086592, >>>>>> 144839226, 148940008.5, 154240128.5, 155887373.5, 178034441.5, >>>>>> 184199138, 184552484), c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, >>>>>> -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, >>>>>> -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, >>>>>> -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18, -0.
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Dear Martin,
On Fri, 07-04-2017, at 12:55:55, Martin Morgan <martin.mor...@roswellpark.org>
wrote:
> On 04/07/2017 03:55 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear Martin and Valerie,
>>
>>
>> I am not sure how to proceed here since the 14th is approaching and I still
>> see this error (in both my package and at least one other package
>> ---arrayQualityMetrics).
>>
>>
>> I could comment out the plotting code for the vignette and examples when
>> running on El Capitan. Is this a possible workaround that I should
>
> In general this is the wrong thing to do, since it enables shipping
> broken code with no possibility of future fixes. Be patient. Martin
Thanks for your answer. I'll be patient :-)
(Just to clarify: I understand that what I was proposing was an ugly
kludge; I think I have misunderstood the issue; apologies for the noise)
Best,
R.
>
>> implement? If this is reasonable, what is the recommended way to find out
>> the code is running in El Capitan and not Mavericks? (For instance, can I
>> tell from Sys.info()["sysname"]? --I do not have access to a Mac).
>>
>>
>> Martin mentioned that the Cairo package requires a binary installation that
>> is not yet available. Should I continue to wait? There is not a lot of
>> margin for changing the code, uploading to BioC, waiting for the build, and
>> making sure it works. What if it continues to fail on El Capitan by the
>> 14th?
>>
>>
>>
>> Best,
>>
>>
>> R.
>>
>>
>>
>>
>> On Mon, 03-04-2017, at 18:34:26, Martin Morgan
>> <martin.mor...@roswellpark.org> wrote:
>>> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>>>
>>>> Dear All,
>>>>
>>>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>>>> segfault that seems to happen when plotting (in a call to plotting that
>>>> happens inside a mclapply)
>>>>
>>>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
>>>>
>>>>
>>>> these are some of the lines of the traceback:
>>>>
>>>> Traceback:
>>>> 1: dev.hold()
>>>> 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199,
>>>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865,
>>>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5,
>>>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738,
>>>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854,
>>>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226,
>>>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484),
>>>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358,
>>>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681,
>>>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123,
>>>> -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371,
>>>> -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio",
>>>> xlab = quote("Chromosomal location"), col = c("orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1,
>>>>axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
>>>> 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5,
>>>> 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734,
>>>> 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5,
>>>> 75218239, 75268559.5, 75683700, 7
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Dear Hervé,
Thanks for your answer. I'll ignore those segfaults then.
Best,
R.
On Fri, 07-04-2017, at 08:36:40, Hervé Pagès <hpa...@fredhutch.org> wrote:
> Hi Ramon,
>
> It doesn't seem that this segfault occurs in ADaCGH2 so you can
> ignore it. I can't be 100% sure but I actually expect it to go away
> when things are sorted out with the new El Capitan binaries.
> Unfortunately it's not something we fully control so let's wait
> and see...
>
> Cheers,
> H.
>
>
> On 04/07/2017 12:55 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear Martin and Valerie,
>>
>>
>> I am not sure how to proceed here since the 14th is approaching and I still
>> see this error (in both my package and at least one other package
>> ---arrayQualityMetrics).
>>
>>
>> I could comment out the plotting code for the vignette and examples when
>> running on El Capitan. Is this a possible workaround that I should
>> implement? If this is reasonable, what is the recommended way to find out
>> the code is running in El Capitan and not Mavericks? (For instance, can I
>> tell from Sys.info()["sysname"]? --I do not have access to a Mac).
>>
>>
>> Martin mentioned that the Cairo package requires a binary installation that
>> is not yet available. Should I continue to wait? There is not a lot of
>> margin for changing the code, uploading to BioC, waiting for the build, and
>> making sure it works. What if it continues to fail on El Capitan by the
>> 14th?
>>
>>
>>
>> Best,
>>
>>
>> R.
>>
>>
>>
>>
>> On Mon, 03-04-2017, at 18:34:26, Martin Morgan
>> <martin.mor...@roswellpark.org> wrote:
>>> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>>>
>>>> Dear All,
>>>>
>>>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>>>> segfault that seems to happen when plotting (in a call to plotting that
>>>> happens inside a mclapply)
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_ADaCGH2_veracruz2-2Dbuildsrc.html=DwIGaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=LUd6DHmjoVArzVDFUEtSRfMSN_AiOXqmmqFV_4As46k=se3QJrNKC3kMzGsf88z7nuqgS_X7o08nzTQ8K7uvai4=
>>>>
>>>>
>>>> these are some of the lines of the traceback:
>>>>
>>>> Traceback:
>>>> 1: dev.hold()
>>>> 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199,
>>>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865,
>>>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5,
>>>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738,
>>>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854,
>>>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226,
>>>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484),
>>>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358,
>>>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681,
>>>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123,
>>>> -0.346, -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371,
>>>> -0.642, -0.13, -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio",
>>>> xlab = quote("Chromosomal location"), col = c("orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>>>> "orange", "orange", "orange", "orange", "orange", "orange"), cex = 1,
>>>>axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
>>>> 3: plot(c(2925836, 5135683.5, 6415674.5, 71697
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Dear Martin and Valerie,
I am not sure how to proceed here since the 14th is approaching and I still
see this error (in both my package and at least one other package
---arrayQualityMetrics).
I could comment out the plotting code for the vignette and examples when
running on El Capitan. Is this a possible workaround that I should
implement? If this is reasonable, what is the recommended way to find out
the code is running in El Capitan and not Mavericks? (For instance, can I
tell from Sys.info()["sysname"]? --I do not have access to a Mac).
Martin mentioned that the Cairo package requires a binary installation that
is not yet available. Should I continue to wait? There is not a lot of
margin for changing the code, uploading to BioC, waiting for the build, and
making sure it works. What if it continues to fail on El Capitan by the
14th?
Best,
R.
On Mon, 03-04-2017, at 18:34:26, Martin Morgan <martin.mor...@roswellpark.org>
wrote:
> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear All,
>>
>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>> segfault that seems to happen when plotting (in a call to plotting that
>> happens inside a mclapply)
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
>>
>>
>> these are some of the lines of the traceback:
>>
>> Traceback:
>> 1: dev.hold()
>> 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199,
>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865,
>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5,
>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738,
>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854,
>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226,
>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484),
>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358,
>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681,
>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346,
>> -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13,
>> -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab =
>> quote("Chromosomal location"), col = c("orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange"), cex = 1, axes =
>> FALSE, main = quote("Chr4@L.1"), pch = 20)
>> 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5,
>> 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734,
>> 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5,
>> 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180,
>> 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724,
>> 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5,
>> 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397,
>> 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172,
>> -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406,
>> 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099,
>> -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33,
>> -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal
>> location"), col = c("orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "
Re: [Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Dear Martin,
Thanks a lot for looking into this. I'll wait then.
Best,
R.
On Mon, 03-04-2017, at 18:34, Martin Morgan <martin.mor...@roswellpark.org>
wrote:
> On 03/31/2017 04:19 AM, Ramon Diaz-Uriarte wrote:
>>
>> Dear All,
>>
>> A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
>> segfault that seems to happen when plotting (in a call to plotting that
>> happens inside a mclapply)
>>
>> http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
>>
>>
>> these are some of the lines of the traceback:
>>
>> Traceback:
>> 1: dev.hold()
>> 2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199,
>> 13220514.5, 15307852, 41589471, 44534348, 47975338, 52729020, 54225865,
>> 54970734, 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5,
>> 72243027.5, 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738,
>> 83724180, 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854,
>> 108945724, 120577571, 122947762.5, 124680401, 129086592, 144839226,
>> 148940008.5, 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484),
>> c(0.397, 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358,
>> 0.172, -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681,
>> -0.406, 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346,
>> -0.099, -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13,
>> -0.33, -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab =
>> quote("Chromosomal location"), col = c("orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange"), cex = 1, axes =
>> FALSE, main = quote("Chr4@L.1"), pch = 20)
>> 3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5,
>> 15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734,
>> 55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5,
>> 75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180,
>> 88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724,
>> 120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5,
>> 154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397,
>> 0.002, -0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172,
>> -0.2435, -0.044, -0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406,
>> 0.083, -0.325, -0.186, -0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099,
>> -0.3465, 0.463, -0.18, -0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33,
>> -0.491, 0.138, -0.187, 0.21), ylab = "log ratio", xlab = quote("Chromosomal
>> location"), col = c("orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange", "orange", "orange", "orange", "orange",
>> "orange", "orange", "orange"), cex = 1, axes = FALSE, main =
>> quote("Chr4@L.1"), pch = 20)
>> 4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))
>>
>>
>>
>> It seems that what triggers the probl
[Bioc-devel] segfault when building in veracruz2 for BioC 3.5
Dear All,
A package I maintain, ADaCGH2, is failing to build in veracruz2 with a
segfault that seems to happen when plotting (in a call to plotting that
happens inside a mclapply)
http://bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/veracruz2-buildsrc.html
these are some of the lines of the traceback:
Traceback:
1: dev.hold()
2: plot.default(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5,
15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734,
55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5,
75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180,
88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724,
120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5,
154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002,
-0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044,
-0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186,
-0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18,
-0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187,
0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col =
c("orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
3: plot(c(2925836, 5135683.5, 6415674.5, 7169722, 9715199, 13220514.5,
15307852, 41589471, 44534348, 47975338, 52729020, 54225865, 54970734,
55406435.5, 57169693.5, 57359284.5, 66362289.5, 69947314.5, 72243027.5,
75218239, 75268559.5, 75683700, 76272391, 76901797, 77282738, 83724180,
88707195.5, 89536816.5, 102463647.5, 104082964, 107610854, 108945724,
120577571, 122947762.5, 124680401, 129086592, 144839226, 148940008.5,
154240128.5, 155887373.5, 178034441.5, 184199138, 184552484), c(0.397, 0.002,
-0.179, -0.1385, -0.095, -0.611, -0.165, -0.54, -0.358, 0.172, -0.2435, -0.044,
-0.048, 0.078, -0.344, -0.139, -0.513, -0.681, -0.406, 0.083, -0.325, -0.186,
-0.138, 0.393, -0.075, -0.655, 0.123, -0.346, -0.099, -0.3465, 0.463, -0.18,
-0.101, -0.175, -0.101, 0.371, -0.642, -0.13, -0.33, -0.491, 0.138, -0.187,
0.21), ylab = "log ratio", xlab = quote("Chromosomal location"), col =
c("orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange", "orange", "orange", "orange", "orange", "orange", "orange",
"orange"), cex = 1, axes = FALSE, main = quote("Chr4@L.1"), pch = 20)
4: do.call(funname, c(list(mf[[i]], y, ylab = yl, xlab = xl), dots))
It seems that what triggers the problem is an innocuous plot.default
followed by dev.hold? (none of which I call explicitly in my code)
At least another package, arrayQualityMetrics seems to experience a
somewhat similar problem:
http://bioconductor.org/checkResults/devel/bioc-LATEST/arrayQualityMetrics/veracruz2-buildsrc.html
where, again, an apparently innocuous plot.default followed by dev.hold
triggers a segfault (and there is no mclapply here)
Traceback:
1: dev.hold()
2: plot.default(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim =
range(min(as.vector(mns)) - 1, max(as.vector(mns)) + 1), xlab = "5'
<-> 3'\n Probe Number ", ylab = ylab, axes = FALSE, main = "RNA
degradation plot", ...)
3: plot(-2, -1, pch = "", xlim = range(-1, (dim(mns)[2])), ylim =
range(min(as.vector(mns)) - 1, max(as.vector(mns)) + 1), xlab = "5' <->
3'\n Probe Number ", ylab = ylab, axes = FALSE, main = "RNA degradation
plot", ...)
4: plotAffyRNAdeg(AffyRNAdeg(expressionset, log.it = TRUE), lwd = 1, cols
= x$arrayColors)
I am not sure how to proceed here. Any suggestions?
Thanks,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] still issues with ggplot2/ggproto in Mac OS X, stable
Hi Hervé,
Thanks for the detailed analysis.
On Wed, 23-11-2016, at 00:41, Hervé Pagès <hpa...@fredhutch.org> wrote:
> Hi Ramon,
>
> All packages (including ggrepel) were re-installed from scratch after we
> updated R on the release build machines one week ago. However it seems
> that re-installing ggrepel on Mac doesn't help. On morelia:
>
> > install.packages("ggrepel")
> --- Please select a CRAN mirror for use in this session ---
> HTTPS CRAN mirror
>
> 1: 0-Cloud [https] 2: Algeria [https]
> 3: Australia (Melbourne) [https] 4: Australia (Perth) [https]
> 5: Austria [https] 6: Belgium (Ghent) [https]
> 7: Brazil (RJ) [https] 8: Brazil (SP 1) [https]
> 9: Bulgaria [https] 10: Canada (MB) [https]
> 11: Chile [https] 12: China (Beijing) [https]
> 13: China (Hefei) [https] 14: China (Lanzhou) [https]
> 15: Colombia (Cali) [https]16: Czech Republic [https]
> 17: Denmark [https]18: France (Lyon 1) [https]
> 19: France (Lyon 2) [https]20: France (Marseille) [https]
> 21: France (Montpellier) [https] 22: France (Paris 2) [https]
> 23: Germany (Falkenstein) [https] 24: Germany (Münster) [https]
> 25: Iceland [https]26: India [https]
> 27: Ireland [https]28: Italy (Padua) [https]
> 29: Japan (Tokyo) [https] 30: Malaysia [https]
> 31: Mexico (Mexico City) [https] 32: New Zealand [https]
> 33: Norway [https] 34: Philippines [https]
> 35: Russia (Moscow) [https]36: Serbia [https]
> 37: Spain (A Coruña) [https] 38: Spain (Madrid) [https]
> 39: Switzerland [https]40: Taiwan (Chungli) [https]
> 41: Turkey (Denizli) [https] 42: UK (Bristol) [https]
> 43: UK (Cambridge) [https] 44: UK (London 1) [https]
> 45: USA (CA 1) [https] 46: USA (IA) [https]
> 47: USA (IN) [https] 48: USA (KS) [https]
> 49: USA (MI 1) [https] 50: USA (TN) [https]
> 51: USA (TX) [https] 52: USA (WA) [https]
> 53: (HTTP mirrors)
>
> Selection: 52
> trying URL
> 'https://cran.fhcrc.org/bin/macosx/mavericks/contrib/3.3/ggrepel_0.6.3.tgz'
> Content type 'unknown' length 802187 bytes (783 KB)
> ==
> downloaded 783 KB
>
>
> The downloaded binary packages are in
> /var/folders/1c/_5ks0mjd3gvf_dq14g3thsr4gn/T//RtmpMwsaS
> /downloaded_packages
> > library(ggrepel)
> Loading required package: ggplot2
> > GeomTextRepel
> Error: GeomTextRepel was built with an incompatible version of ggproto.
> Please reinstall the package that provides this extension.
>
> So it looks like the Mac binary itself is broken. Note that the CRAN
> check results for ggrepel are OK:
>
>http://cran.fhcrc.org/web/checks/check_results_ggrepel.html
>
> but that's because 'R CMD check' cannot detect a stale binary package
> because it is run on the source package.
>
OK, I did not realize that.
> The timestamp for ggrepel_0.6.3.tgz can be seen here:
>
>http://cran.fhcrc.org/bin/macosx/mavericks/contrib/3.3/
>
> It indicates that the binary was made on 21-Oct-2016 which predates the
> latest change in ggplot2 (2016-11-11) that is supposedly the culprit.
>
Got it.
> That means the ggrepel Mac binary would need to be re-generated.
> Someone would need to contact the CRAN people about this with Cc the
> ggrepel people. Probably the best solution is for the ggrepel people to
> bump the version of their package otherwise people who already have the
> old broken binary installed on their machine won't get the new binary
> when doing update.packages().
>
> Note that the Windows binary doesn't have this problem because it was
> generated on 20-Nov-2016 i.e. after the change in ggplot2:
>
>http://cran.fhcrc.org/bin/windows/contrib/3.3/
>
> Finally note that we could work around the problem on morelia by
> re-installing ggrepel from source but that would just put a lid on
> the problem: the end user would still see the problem on his/her
> machine.
I am writing the maintainer of ggrepel (I've CC'd you). I am attaching your
full email, so he can see the full details, but I am suggesting explicitly
bumping the version, since as you explain trying to get it regenerated in
CRAN is only a partial solution (and trying to get CRAN to do that might be
also more complicated).
Thanks again,
R.
>
> Cheers,
> H.
>
>
> On 11/22/2016 02:14 PM, Ramon Diaz-Uriarte wrote:
>> Dear All,
>>
>> Sorry to return to this issue, but on Morelia (Mac OS X, stable), we are
>> still seeing packages break during build with this message
>
[Bioc-devel] still issues with ggplot2/ggproto in Mac OS X, stable
Dear All, Sorry to return to this issue, but on Morelia (Mac OS X, stable), we are still seeing packages break during build with this message "GeomTextRepel was built with an incompatible version of ggproto. Please reinstall the package that provides this extension. Execution halted" that affects many (all?) packages that depend on ggrepel or other packages that depend on ggplot2/ggproto. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] recent changes in ggplot2 break some packages
Hi Diego, On Mon, 14-11-2016, at 12:25, Diego Diez <diego10r...@gmail.com> wrote: > Hi Ramon, > > My experience with this issue is that it requires reinstalling the > depending packages from source (but not ggplot2 itself). Makes sense (in my machines, I just reinstalled both, for the sake of expediency :-) so I should have said that was sufficient but wasn't sure what was necessary). > Alternatively, this should be fixed (I think) once all dependent > packages are rebuilt with the newest ggplot2 installed. See this > related post in the ggtree package issue tracker: > > https://github.com/GuangchuangYu/ggtree/issues/91 Thanks for the link. Best, R. > > Best, > Diego > > On Mon, Nov 14, 2016 at 7:50 PM, Ramon Diaz-Uriarte <rdia...@gmail.com> wrote: >> Dear All, >> >> At least some packages (partial list in links below) are failing checks in >> both release and devel; the error logs for Linux, Windows, and Mac all show >> >> >> "Error: processing vignette 'OncoSimulR.Rmd' failed with diagnostics: >> [GeomTextRepel/PositionQuasirandom/etc] was built with an incompatible >> version of ggproto. Please reinstall the package that provides this >> extension." >> >> >> A partial list for devel: >> http://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/malbec2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/cytofkit/malbec2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/maftools/malbec2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/MoonlightR/malbec2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/pcaExplorer/malbec2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/scater/malbec2-buildsrc.html >> >> >> >> For release: >> http://bioconductor.org/checkResults/release/bioc-LATEST/OncoSimulR/malbec1-buildsrc.html >> http://bioconductor.org/checkResults/release/bioc-LATEST/cytofkit/malbec1-buildsrc.html >> etc >> >> >> This seems related to very recent changes in ggplot2 (and other people have >> reported similar problems in oter forums). It is fixed reinstalling ggplot2 >> and the other package that depends on it (e.g., ggrepel)[1]. >> >> Should we just wait for ggplot2 and ggrepel to be reinstalled in the build >> machines? How often do these happen? >> >> >> Best, >> >> >> R. >> >> >> [1] And, at least for the package I maintain, OncoSimulR, there are no >> issues with R-devel in my local machines or with Travis >> (https://travis-ci.org/rdiaz02/OncoSimul), or Appveyor >> (https://ci.appveyor.com/project/rdiaz02/OncoSimul). >> >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >>ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] recent changes in ggplot2 break some packages
Dear All, At least some packages (partial list in links below) are failing checks in both release and devel; the error logs for Linux, Windows, and Mac all show "Error: processing vignette 'OncoSimulR.Rmd' failed with diagnostics: [GeomTextRepel/PositionQuasirandom/etc] was built with an incompatible version of ggproto. Please reinstall the package that provides this extension." A partial list for devel: http://bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/malbec2-buildsrc.html http://bioconductor.org/checkResults/devel/bioc-LATEST/cytofkit/malbec2-buildsrc.html http://bioconductor.org/checkResults/devel/bioc-LATEST/maftools/malbec2-buildsrc.html http://bioconductor.org/checkResults/devel/bioc-LATEST/MoonlightR/malbec2-buildsrc.html http://bioconductor.org/checkResults/devel/bioc-LATEST/pcaExplorer/malbec2-buildsrc.html http://bioconductor.org/checkResults/devel/bioc-LATEST/scater/malbec2-buildsrc.html For release: http://bioconductor.org/checkResults/release/bioc-LATEST/OncoSimulR/malbec1-buildsrc.html http://bioconductor.org/checkResults/release/bioc-LATEST/cytofkit/malbec1-buildsrc.html etc This seems related to very recent changes in ggplot2 (and other people have reported similar problems in oter forums). It is fixed reinstalling ggplot2 and the other package that depends on it (e.g., ggrepel)[1]. Should we just wait for ggplot2 and ggrepel to be reinstalled in the build machines? How often do these happen? Best, R. [1] And, at least for the package I maintain, OncoSimulR, there are no issues with R-devel in my local machines or with Travis (https://travis-ci.org/rdiaz02/OncoSimul), or Appveyor (https://ci.appveyor.com/project/rdiaz02/OncoSimul). -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] BioC 3.4: several package failures traceable to vsn req. R >= 3.4.0?
Thanks Hervé. R. On Mon, 17-10-2016, at 11:32, Hervé Pagès <hpa...@fredhutch.org> wrote: > Hi Ramon, > > Yes the issue is known. The vsn maintainers have fixed the problem > yesterday in svn, right before the builds started. All the failures > due to vsn not installing on the build machines should be gone in > today's report. > > Cheers, > H. > > On 10/17/2016 01:34 AM, Ramon Diaz-Uriarte wrote: >> Dear All, >> >> Several packages (at least ADaCGH2, snapCGH, tilingArray, cellHTS2) are now >> (last 24 to 48 hours?) failing to build in BioC 3.4 in Linux (malbec1) and >> Mac OSX (morelia). Looking at the error reports they seem to be due to vsn >> not being available. Checking the vsn report >> (http://bioconductor.org/checkResults/3.4/bioc-LATEST/vsn) it seems vsn >> required R-3.4.0 at the time of the check. However, the new vsn on the svn >> repo (v.3.41.8) has >> >> Depends: R (>= 3.0.0), Biobase >> >> >> So I guess we just need to wait for vsn to be rebuilt? I would normally >> just wait quietly, but I am concerned because I think the creation of the >> BioC 3.4 release branch is today and release is tomorrow. >> >> Best and apologies for the noise if this issue is known, >> >> >> R. >> >> >> -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] BioC 3.4: several package failures traceable to vsn req. R >= 3.4.0?
Dear All, Several packages (at least ADaCGH2, snapCGH, tilingArray, cellHTS2) are now (last 24 to 48 hours?) failing to build in BioC 3.4 in Linux (malbec1) and Mac OSX (morelia). Looking at the error reports they seem to be due to vsn not being available. Checking the vsn report (http://bioconductor.org/checkResults/3.4/bioc-LATEST/vsn) it seems vsn required R-3.4.0 at the time of the check. However, the new vsn on the svn repo (v.3.41.8) has Depends: R (>= 3.0.0), Biobase So I guess we just need to wait for vsn to be rebuilt? I would normally just wait quietly, but I am concerned because I think the creation of the BioC 3.4 release branch is today and release is tomorrow. Best and apologies for the noise if this issue is known, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] platforms "some" on devel?
Yes, that was the strange thing (for me at least): some packages showed "all" and some showed "some" and a cursory look did not reveal any pattern. R. On Fri, 23-09-2016, at 08:26, Hervé Pagès <hpa...@fredhutch.org> wrote: > On 09/22/2016 11:09 PM, Ramon Diaz-Uriarte wrote: >> Hi Hervé, >> >> Thanks for the clarification; (what I was surprised about was that some say >> "some" and others said "all", > > Oh really? I went directly to the landing page of your package, saw > the "some", and didn't mind checking other package landing pages. > Weird indeed. > >> but never mind as things are now back to >> their usual state). > > Yep. > > Cheers, > H. > >> >> Best, >> >> R. >> >> >> On Thu, 22-09-2016, at 19:05, Hervé Pagès <hpa...@fredhutch.org> wrote: >>> Hi Ramon, >>> >>> The Mac builder morelia is slow and has not finished yet. >>> >>> Hopefully the badge situation is transient and the badges will >>> automatically update after the build report gets re-generated >>> later today with the results for Mac. >>> >>> Thanks for your patience, >>> H. >>> >>> On 09/22/2016 09:37 AM, Ramon Diaz-Uriarte wrote: >>>> >>>> Dear All, >>>> >>>> At least some packages (e.g., ADaCGH2 or OncoSimulR ---two I maintain---, >>>> but also a bunch of others), but not all packages, show "some" in the badge >>>> for platforms, but the build report does not show explicit failure of the >>>> package on Mac and it seems there has been no successful build on the Mac >>>> for a couple of days >>>> (http://bioconductor.org/checkResults/3.4/bioc-LATEST/index.html). >>>> >>>> >>>> Best, >>>> >>>> R. >>>> >>>> >> >> -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Citation info still not displayed correctly for some packages
Martin, thanks a lot and thanks too for the details and the workaround for
packageDescription.
best,
R.
On Tue, 30-08-2016, at 00:17, Martin Morgan <martin.mor...@roswellpark.org>
wrote:
> On 08/29/2016 05:40 PM, Ramon Diaz-Uriarte wrote:
>>
>> Dear All,
>>
>> At least for some packages
>> (http://bioconductor.org/packages/devel/bioc/html/OncoSimulR.html) the
>> citation info is still not displayed correctly. I double checked installing
>> from BioC just now, and the citation is not the one shown in the landing
>> page on BioC; the vignette
>> (http://www.bioconductor.org/packages/3.4/bioc/vignettes/OncoSimulR/inst/doc/OncoSimulR.html#15_citing_oncosimulr_and_other_documentation)
>> also shows the output from citation("OncoSimulR"), which again is not the
>> same as in the BioC page.
>>
>> I think that at least in this case the citation info has not been updated
>> in the last two builds.
>
> biocViews (which processes the citations) was updated in the last build,
> it should be used in the next build. I'll keep an eye on it.
>
> OncoSimulR seems to have a valid CITATION file.
>
> For a little more information, there are a number of outstanding
> problems with citation processing. Citation information is added using
> readCitationFile() applied to the package _source_, rather than the
> installed package. This is because some packages (those without any
> reverse dependencies) are never actually installed on the build system
> -- they are built into a tar ball and checked, and the built tarball is
> used to generate citation information.
>
> This means that CITATION files that do things like
> packageDescription("foo") fail, because "foo" is not installed. The
> current solution is to rely on the 'meta' argument to
> readCitationFile(), so CITATION files can replace lines like
>
> version <- packageDescription("foo")$Version
>
> with
>
> version <- meta$Version
>
> or more flexibly
>
> if (!exists("meta") || is.null(meta))
> meta <- packageDescription("nlme")
>
> and one can test that one has a valid CITATION file with
>
> descr = packageDescription("pkg-name", "/path/to/pkg")
> readCitationFile("/path/to/pkg/pkg-name/inst/CITATION", descr)
>
> There are related problems, e.g., with use of the knitrcitation or
> omitting the required field 'textVersion', and a bug (generating a
> warning, but apparently not compromising the citation) when a url or doi
> field contains an encoded url, as
>
> > xx <<- "\\url{http://foo%3Fbar};; con <- textConnection(xx);
> parse_Rd(con, fragment=TRUE, permissive=TRUE)
> Warning in withCallingHandlers(.External2(C_parseRd, tcon, srcfile,
> "UTF-8", :
>:2: unexpected END_OF_INPUT '
> '
> \url{http://foo%3Fbar}
> }
>
> Here is a summary of the issues I know about; the 'err' and 'warn'
> labels refer to how R reports the initial error; the packageDescription
> 'warnings' actually mean that the CITATION file may not be parsed by the
> build system.
>
> ## > names(err)
> ## [1] "bioassayR"# knitcitations()
> ## [2] "ChemmineR"# knitcitations()
> ## [3] "clippda" # missing textVersion
> ## [4] "eiR" # knitcitations()
> ## [5] "fmcsR"# knitcitations()
> ## [6] "metagenomeSeq"# packageVersion()
> ## [7] "SomatiCA" # missing textVersion
> ## > names(warn)
> ## [1] "ALDEx2" # url encoding '10.1371%2'
> ## [2] "aroma.light" # print(citn, style="html"); trailing } in title
> ## [3] "birte" # packageDescription()
> ## [4] "BRAIN" # packageDescription()
> ## [5] "ChAMP" # doi encoding %2F
> ## [6] "ChIPpeakAnno"# url encoding %2F
> ## [7] "CoGAPS" # packageDescription()
> ## [8] "derfinderHelper" # packageDescription()
> ## [9] "derfinderPlot"
> ## [10] "destiny" # packageDescription()
> ## [11] "fabia" # packageDescription()
> ## [12] "flowFP" # packageDescription()
> ## [13] "GenomicAlignments"# url encoding
> ## [14] "GenomicFeatures" # url encoding
> ## [15] "GenomicRanges"# url encoding
> ## [16] "Genominator" # packageDescription()
> ## [17] "GOSim" # packageDescription()
> ## [18] "GSRI"# packageDescription()
> ## [19] "hapFabia"# packageDescription()
> ## [20] "kebabs
[Bioc-devel] Citation info still not displayed correctly for some packages
Dear All,
At least for some packages
(http://bioconductor.org/packages/devel/bioc/html/OncoSimulR.html) the
citation info is still not displayed correctly. I double checked installing
from BioC just now, and the citation is not the one shown in the landing
page on BioC; the vignette
(http://www.bioconductor.org/packages/3.4/bioc/vignettes/OncoSimulR/inst/doc/OncoSimulR.html#15_citing_oncosimulr_and_other_documentation)
also shows the output from citation("OncoSimulR"), which again is not the
same as in the BioC page.
I think that at least in this case the citation info has not been updated
in the last two builds.
Best,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?
On Fri, 19-08-2016, at 15:41, Sean Davis <seand...@gmail.com> wrote: >> On Aug 19, 2016, at 9:10 AM, Ramon Diaz-Uriarte <rdia...@gmail.com> wrote: >> >> >> >> >> On Wed, 17-08-2016, at 15:08, Sean Davis <seand...@gmail.com> wrote: >>>> On Aug 17, 2016, at 8:55 AM, Martin Morgan <martin.mor...@roswellpark.org> >>>> wrote: >>>> >>>> On 08/17/2016 07:02 AM, Henrik Bengtsson wrote: >>>>> R CMD build, which is what triggers vignette building, only supports one >>>>> output file (HTML or PDF) per vignette. It will basically ignore duplicate >>>>> output formats. This is by design / legacy reasons. Technically it >>>>> wouldn't >>>>> be hard to add support for multiple output formats, but that would require >>>>> changes to R itself - I think it could be a useful feature. >>>>> >>>>> A related question is where some prefer to have access to also the >>>>> intermediate plain Markdown / TeX rather than the final HTML / PDF >>>>> product, >>>>> e.g. because they work better with screen readers. >>>>> >>>>> The only way I see you can have a PDF and a HTML version at the same time >>>>> is to create to identical vignettes each outputting a specific format. >>>> >>>> A consideration from the build machine perspective is the cost to process >>>> the vignettes, in particular the code chunks. These would be done across >>>> platforms and vignettes, because the build system wouldn't know about the >>>> trickery you're engaged in. >>>> >>>> Also from the end user perspective I don't think having two vignettes with >>>> identical content is particularly helpful; as a user I wouldn't be >>>> confident that they were equally current (however adeptly the duplication >>>> of content were implemented). >>>> >>>> Personally, I think the HTML presentation is much more conducive to the >>>> way vignettes are used. >>> >>> And with some CSS trickery (may not even be needed if basing things on an >>> established CSS framework), an HTML vignette can be rendered in a very nice >>> printable form if folks want to print it. >>> >>> http://stackoverflow.com/a/12303057/459633 >>> >> >> Thanks Sean, didn't know about that. >> >> But then, doesn't this somehow defeats part of the purpose (or the spirit) >> of R markdown: a single file, with low barrier of entry, that allows you to >> produce HTML, PDF (and epub) just by calling one or another function in the >> call to render? (Context: after having used LaTeX for mny years, I am >> finding the markdown experience painful and disconcerting; the idea of >> handling CSS trickery looks like additional pain and suprises :-). > > Hi, Ramone. > > Well, before worrying too much about needing to do extra work, take a look at > this page: > > http://bioconductor.org/packages/release/bioc/vignettes/BiocStyle/inst/doc/HtmlStyle.html > > Then, choose “print page”. As you can see, the rendered pdf is actually > quite usable, including page numbers, clickable TOC, and originating URL. > If you were to take a look at the CSS for biocstyle, it does not include > any special “trickery” for printing, but it could if there is behavior > needed beyond the “default”. > Thanks Sean. You are right: this is a very usable PDF and can be obtained very easily. (Just for the record, and in case someone else stumbles upon this, at least under Linux clickable links can depend a lot on the browser; chrome does it fine, but for Firefox links are not preserved, unless one uses one of the extensions available. htmldoc and wkhtmltopdf also work fine from the command line). Best, R. > That said, I still use .Rnw for some things where I want the true print > beauty of LaTeX, but for collaborators, vignettes, and everyday work, I > still find rmarkdown compelling. Moving beyond the single vignette, the > ecosystem around markdown is impressive, particularly with respect to > HTML/web. > > Sean > > >> >> >> As the one producing the vignette, what do I gain from inserting a link in >> the HTML vignette that points to a place where I've left the PDF (produced >> using pdf_document or similar)? (Aside from not inserting the link and not >> having to produce the PDF, which can be automated via hooks or similar). >> >> >> >> >> Best, &g
Re: [Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?
On Thu, 18-08-2016, at 16:45, Wolfgang Huber <whu...@embl.de> wrote:
>> On 17 Aug 2016, at 13:02, Henrik Bengtsson <henrik.bengts...@gmail.com>
>> wrote:
>>
>> R CMD build, which is what triggers vignette building, only supports one
>> output file (HTML or PDF) per vignette. It will basically ignore duplicate
>> output formats. This is by design / legacy reasons. Technically it wouldn't
>> be hard to add support for multiple output formats, but that would require
>> changes to R itself - I think it could be a useful feature.
>
> Henrik, I’m sure you have more experience and insight with this than I, but I
> wonder when (at what stage) and what for R needs to be changed? It seems
> there are several issues:
> (a) having both the PDF and HTML be built by the build system and be shipped
> with the package
> (b) making them discoverable on the Bioc package landing page, and on the
> index page of the R-help system.
> (c) making (a) and (b) easy and standardized for package authors
>
> Re (a), on first sight, it seems that simply adding the YAML lines Ramon
> mentioned to the vignette will NOT achieve this (it looks like only
> whatever is the first output format stated, is produced), but according
> to
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Writing-package-vignettes
> https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Non_002dSweave-vignettes
> I expect that with sufficient cleverness with (i) a Makefile and/or (ii)
> registering your own VignetteBuilder (some wrapper around knitr::render
> that makes sure both outputs are built, with only one run of the R code)
> it should be possible to achieve (a).
>
> For something almost as good as (b) [or better?], you could have the HTML
> indexed, and in it e.g. at the top have a button with a link to the PDF
> file, for those who want to print it.
bookdown::gitbook (https://bookdown.org/yihui/bookdown/html.html) provides
those buttons (PDF, epub, etc): and some other niceties (though I have not
had luck getting the TOC to behave as I wanted with single-file vignettes).
R.
>
> For (c), I suppose changing R would be handy. Or BiocStyle?
>
> Wolfgang
>
>
>>
>
>> A related question is where some prefer to have access to also the
>> intermediate plain Markdown / TeX rather than the final HTML / PDF product,
>> e.g. because they work better with screen readers.
>>
>> The only way I see you can have a PDF and a HTML version at the same time
>> is to create to identical vignettes each outputting a specific format.
>>
>> Henrik
>>
>> On Aug 17, 2016 12:17, "Ramon Diaz-Uriarte" <rdia...@gmail.com> wrote:
>>
>>>
>>> Dear All,
>>>
>>> I am considering rewriting the vignette of one BioC package I maintain as
>>> Rmd (it is currently Rnw). But I would like that the entry under
>>> "Documentation" contain a PDF of the vignette; it can ideally also contain
>>> the HTML version too, but I do not want it to not have the PDF[1].
>>>
>>>
>>> I know I can add entries to the document header such as
>>>
>>> output:
>>> BiocStyle::pdf_document:
>>>toc: true
>>> BiocStyle::html_document:
>>>toc: true
>>>
>>>
>>> that will, when run locally via "render('file.Rmd', output_format =
>>> 'all')", produce both formats.
>>>
>>>
>>>
>>> I've googled around, but I am not sure about:
>>>
>>> 1. If I have both output formats specified in the document header, will the
>>> BioC page of the package actually show both the PDF and the HTML of the
>>> vignette?
>>>
>>>
>>> 2. Is it OK (in conforming with BioC policies, sensible[1], whatever) to
>>> even try/want this? My reading of the doc for the BiocStyle
>>> (https://www.bioconductor.org/packages/devel/bioc/vignettes/
>>> BiocStyle/inst/doc/HtmlStyle.html)
>>> seems to suggest that the "natural" thing for Rmd vignettes is to be
>>> rendered as HTML, but I have not seen that producing PDF is discouraged
>>> explicitly.
>>>
>>>
>>> Best,
>>>
>>>
>>> R.
>>>
>>>
>>> [1] Why do I want to get a PDF if I am using Rmd? I want a PDF because this
>>> is a fairly long document that some users want to be able to print. I want
>>> HTML because some users prefer HTML and because I'd like to also place the
>>> vignette as HTML in Github Pages. I think that the only way t
Re: [Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?
On Wed, 17-08-2016, at 15:08, Sean Davis <seand...@gmail.com> wrote:
>> On Aug 17, 2016, at 8:55 AM, Martin Morgan <martin.mor...@roswellpark.org>
>> wrote:
>>
>> On 08/17/2016 07:02 AM, Henrik Bengtsson wrote:
>>> R CMD build, which is what triggers vignette building, only supports one
>>> output file (HTML or PDF) per vignette. It will basically ignore duplicate
>>> output formats. This is by design / legacy reasons. Technically it wouldn't
>>> be hard to add support for multiple output formats, but that would require
>>> changes to R itself - I think it could be a useful feature.
>>>
>>> A related question is where some prefer to have access to also the
>>> intermediate plain Markdown / TeX rather than the final HTML / PDF product,
>>> e.g. because they work better with screen readers.
>>>
>>> The only way I see you can have a PDF and a HTML version at the same time
>>> is to create to identical vignettes each outputting a specific format.
>>
>> A consideration from the build machine perspective is the cost to process
>> the vignettes, in particular the code chunks. These would be done across
>> platforms and vignettes, because the build system wouldn't know about the
>> trickery you're engaged in.
>>
>> Also from the end user perspective I don't think having two vignettes with
>> identical content is particularly helpful; as a user I wouldn't be confident
>> that they were equally current (however adeptly the duplication of content
>> were implemented).
>>
>> Personally, I think the HTML presentation is much more conducive to the way
>> vignettes are used.
>
> And with some CSS trickery (may not even be needed if basing things on an
> established CSS framework), an HTML vignette can be rendered in a very nice
> printable form if folks want to print it.
>
> http://stackoverflow.com/a/12303057/459633
>
Thanks Sean, didn't know about that.
But then, doesn't this somehow defeats part of the purpose (or the spirit)
of R markdown: a single file, with low barrier of entry, that allows you to
produce HTML, PDF (and epub) just by calling one or another function in the
call to render? (Context: after having used LaTeX for mny years, I am
finding the markdown experience painful and disconcerting; the idea of
handling CSS trickery looks like additional pain and suprises :-).
As the one producing the vignette, what do I gain from inserting a link in
the HTML vignette that points to a place where I've left the PDF (produced
using pdf_document or similar)? (Aside from not inserting the link and not
having to produce the PDF, which can be automated via hooks or similar).
Best,
R.
> Sean
>
>
>>
>> Martin
>>
>>
>>>
>>> Henrik
>>>
>>> On Aug 17, 2016 12:17, "Ramon Diaz-Uriarte" <rdia...@gmail.com> wrote:
>>>
>>>>
>>>> Dear All,
>>>>
>>>> I am considering rewriting the vignette of one BioC package I maintain as
>>>> Rmd (it is currently Rnw). But I would like that the entry under
>>>> "Documentation" contain a PDF of the vignette; it can ideally also contain
>>>> the HTML version too, but I do not want it to not have the PDF[1].
>>>>
>>>>
>>>> I know I can add entries to the document header such as
>>>>
>>>> output:
>>>> BiocStyle::pdf_document:
>>>>toc: true
>>>> BiocStyle::html_document:
>>>>toc: true
>>>>
>>>>
>>>> that will, when run locally via "render('file.Rmd', output_format =
>>>> 'all')", produce both formats.
>>>>
>>>>
>>>>
>>>> I've googled around, but I am not sure about:
>>>>
>>>> 1. If I have both output formats specified in the document header, will the
>>>> BioC page of the package actually show both the PDF and the HTML of the
>>>> vignette?
>>>>
>>>>
>>>> 2. Is it OK (in conforming with BioC policies, sensible[1], whatever) to
>>>> even try/want this? My reading of the doc for the BiocStyle
>>>> (https://www.bioconductor.org/packages/devel/bioc/vignettes/
>>>> BiocStyle/inst/doc/HtmlStyle.html)
>>>> seems to suggest that the "natural" thing for Rmd vignettes is to be
>>>> rendered as HTML, but I have not seen that producing PDF is discouraged
>>>> explicitly.
>>>>
>>>>
>>>> Best,
>>>>
>&g
[Bioc-devel] Is it OK for Rmd package vignettes to be rendered as PDF?
Dear All,
I am considering rewriting the vignette of one BioC package I maintain as
Rmd (it is currently Rnw). But I would like that the entry under
"Documentation" contain a PDF of the vignette; it can ideally also contain
the HTML version too, but I do not want it to not have the PDF[1].
I know I can add entries to the document header such as
output:
BiocStyle::pdf_document:
toc: true
BiocStyle::html_document:
toc: true
that will, when run locally via "render('file.Rmd', output_format =
'all')", produce both formats.
I've googled around, but I am not sure about:
1. If I have both output formats specified in the document header, will the
BioC page of the package actually show both the PDF and the HTML of the
vignette?
2. Is it OK (in conforming with BioC policies, sensible[1], whatever) to
even try/want this? My reading of the doc for the BiocStyle
(https://www.bioconductor.org/packages/devel/bioc/vignettes/BiocStyle/inst/doc/HtmlStyle.html)
seems to suggest that the "natural" thing for Rmd vignettes is to be
rendered as HTML, but I have not seen that producing PDF is discouraged
explicitly.
Best,
R.
[1] Why do I want to get a PDF if I am using Rmd? I want a PDF because this
is a fairly long document that some users want to be able to print. I want
HTML because some users prefer HTML and because I'd like to also place the
vignette as HTML in Github Pages. I think that the only way to accomplish
both is to use Rmd (not Rnw, even if I really, really, prefer LaTeX :-).
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] "platforms" information not updated
Hi Dan, Thanks for fixing it. R. On Tue, 26-07-2016, at 21:27, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > Hi Ramon, > > Thanks for letting us know about this. We've identified and fixed the problem. > > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "bioc-devel" <bioc-devel@r-project.org> >> Cc: "ramon diaz" <ramon.d...@iib.uam.es> >> Sent: Monday, July 25, 2016 11:30:39 AM >> Subject: [Bioc-devel] "platforms" information not updated > >> Dear All, >> >> A package I maintain, OncoSimulR, shows "some" for platforms, but when one >> clicks on the badge, in both the release and the development version >> >> http://bioconductor.org/packages/release/bioc/html/OncoSimulR.html#archives >> >> http://bioconductor.org/packages/3.4/bioc/html/OncoSimulR.html#archives >> >> one can see that it is available as source, as Windows binary, and as tgz >> for Mac OS X 10.9. Thus, it is available for all currently supported >> platforms. The "some" I think is a legacy from the past (this package was not >> supported in a version of Mac OS that is no longer supported by BioC >> either). >> >> >> How can this be fixed, so that the information is updated? >> >> Thanks, >> >> >> R. >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] "platforms" information not updated
Dear All, A package I maintain, OncoSimulR, shows "some" for platforms, but when one clicks on the badge, in both the release and the development version http://bioconductor.org/packages/release/bioc/html/OncoSimulR.html#archives http://bioconductor.org/packages/3.4/bioc/html/OncoSimulR.html#archives one can see that it is available as source, as Windows binary, and as tgz for Mac OS X 10.9. Thus, it is available for all currently supported platforms. The "some" I think is a legacy from the past (this package was not supported in a version of Mac OS that is no longer supported by BioC either). How can this be fixed, so that the information is updated? Thanks, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] no build reports (nor builds) for Windows in BioC 3.4
Dear Andrzej, On Mon, 04-07-2016, at 15:13, Andrzej Oleś <andrzej.o...@gmail.com> wrote: > I'm sorry, I didn't notice the Windows part in the message subject. I should have been explicit in the message body. My fault. > > Indeed, the windows builder in devel seems to be offline. For example, the > the latest version of BiocStyle available from the website is 2.1.4, while > the subsequent version 2.1.5 was committed almost a month ago on Jun 9. > Thanks for confirming. And thanks for that example (the ones I checked were only a week to 10 days old). > I'm not sure what happened to the windows machine, maybe someone from the > core team has more insight into this. > Best, R. P.S. Sorry for misspelling your name in the previous email :-) > Cheers, > Andrzej > > On Mon, Jul 4, 2016 at 2:10 PM, Ramon Diaz-Uriarte <rdia...@gmail.com> > wrote: > >> Hi Andrezj, >> >> Sorry, the text of the message was not explicit (but the subject message >> was): no builds for **Windows**. >> >> So, yes, the page says "This page was generated on 2016-07-03 15:29:33 >> -0700 (Sun, 03 Jul 2016)." >> >> but there are not reports for Windows, only for machines zin1 (Linux) and >> Morelia (Mac). You can also see this if, from the page of any package in >> devel, you click on the build status badge: you only get them from zin1 and >> morelia, not for any windows machine. >> >> And for at least some packages, the Windows version is lagging behind the >> Linux and Macs versions (consistent with the idea of no builds for at least >> a weak). >> >> >> >> Best, >> >> >> >> R. >> >> On Mon, 04-07-2016, at 13:02, Andrzej Oleś <andrzej.o...@gmail.com> wrote: >> > Hi Ramon, >> > >> > why do you think there have been no build in the past week? The header on >> > the page you provided says: >> > >> > *This page was generated on 2016-07-03 15:29:33 -0700 (Sun, 03 Jul >> 2016).* >> > From what I see the builds are up to date and reflect recent changes to >> the >> > svn. >> > >> > Maybe some browser caching issue on your side? >> > >> > Cheers, >> > Andrzej >> > >> > On Mon, Jul 4, 2016 at 12:50 PM, Ramon Diaz-Uriarte <rdia...@gmail.com> >> > wrote: >> > >> >> >> >> Dear All, >> >> >> >> During at least the last eight days I think there have been no new >> builds, >> >> nor build reports, for BioC 3.4 (devel): >> >> >> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/ >> >> >> >> Is this on purpose? >> >> >> >> >> >> Best, >> >> >> >> >> >> R. >> >> >> >> >> >> -- >> >> Ramon Diaz-Uriarte >> >> Department of Biochemistry, Lab B-25 >> >> Facultad de Medicina >> >> Universidad Autónoma de Madrid >> >> Arzobispo Morcillo, 4 >> >> 28029 Madrid >> >> Spain >> >> >> >> Phone: +34-91-497-2412 >> >> >> >> Email: rdia...@gmail.com >> >>ramon.d...@iib.uam.es >> >> >> >> http://ligarto.org/rdiaz >> >> >> >> ___ >> >> Bioc-devel@r-project.org mailing list >> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >>ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] no build reports (nor builds) for Windows in BioC 3.4
Hi Andrezj, Sorry, the text of the message was not explicit (but the subject message was): no builds for **Windows**. So, yes, the page says "This page was generated on 2016-07-03 15:29:33 -0700 (Sun, 03 Jul 2016)." but there are not reports for Windows, only for machines zin1 (Linux) and Morelia (Mac). You can also see this if, from the page of any package in devel, you click on the build status badge: you only get them from zin1 and morelia, not for any windows machine. And for at least some packages, the Windows version is lagging behind the Linux and Macs versions (consistent with the idea of no builds for at least a weak). Best, R. On Mon, 04-07-2016, at 13:02, Andrzej Oleś <andrzej.o...@gmail.com> wrote: > Hi Ramon, > > why do you think there have been no build in the past week? The header on > the page you provided says: > > *This page was generated on 2016-07-03 15:29:33 -0700 (Sun, 03 Jul 2016).* > From what I see the builds are up to date and reflect recent changes to the > svn. > > Maybe some browser caching issue on your side? > > Cheers, > Andrzej > > On Mon, Jul 4, 2016 at 12:50 PM, Ramon Diaz-Uriarte <rdia...@gmail.com> > wrote: > >> >> Dear All, >> >> During at least the last eight days I think there have been no new builds, >> nor build reports, for BioC 3.4 (devel): >> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/ >> >> Is this on purpose? >> >> >> Best, >> >> >> R. >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >>ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] test coverage not shown
Dear All, For both Bioc 3.3 and Bioc 3.4, test coverage is shown as "unknown" for (at least some) packages that do have tests. (As an example, one package I maintain: https://www.bioconductor.org/packages/release/bioc/html/OncoSimulR.html and https://www.bioconductor.org/packages/devel/bioc/html/OncoSimulR.html). Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] some new warnings in a package
On Fri, 29-04-2016, at 23:49, Martin Morgan <martin.mor...@roswellpark.org> wrote: > On 04/29/2016 05:23 PM, Ramon Diaz-Uriarte wrote: >> Dear All, >> >> In case it matters, and since we are past the 22, I just noticed that a >> package I maintain (ADaCGH2) is giving warnings in Linux and Mac (e.g., >> https://www.bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/zin2-checksrc.html) >> that, if I recall correctly, were not being given around the 22nd. I think >> these warnings have started appearing with the latest Rs in BioC (around >> r70549?). I haven't been able to understand the ultimate cause of the >> warnings (as they seem to refer to issues that are not in the code of my >> package), but they disappear when I move a package from Imports to Depends. > > They seem to come from GLAD's use of packageStartupMessage() in .onLoad > (e.g., when the package is imported) rather than the recommended > .onAttach (when the package is attached to the search() path, e.g., via > library() or Depends: in the DESCRIPTION file). > > I updated GLAD to use packageStartuupMessage() in .onAttach; I think the > warnings will go away. Martin, thanks for the reply and details. And sorry for my not-particularly-explicit message; yes, GLAD is the package that I moved to Depends. And I did not say (though I had intended too ---time to go to bed) that I had committed my changes to svn. Anyway, should I revert my changes to keep GLAD in Imports? Best, R. > > Martin > >> >> >> Best, >> >> R. >> >> >> >> > > > 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. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] some new warnings in a package
Dear All, In case it matters, and since we are past the 22, I just noticed that a package I maintain (ADaCGH2) is giving warnings in Linux and Mac (e.g., https://www.bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/zin2-checksrc.html) that, if I recall correctly, were not being given around the 22nd. I think these warnings have started appearing with the latest Rs in BioC (around r70549?). I haven't been able to understand the ultimate cause of the warnings (as they seem to refer to issues that are not in the code of my package), but they disappear when I move a package from Imports to Depends. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [R-pkg-devel] Has GitHub been used as a CRAN-style repository?
Dear Bruce, On Wed, 27-04-2016, at 19:00, Bruce Hoff <bruce.h...@sagebase.org> wrote: > Following up to my earlier post: It looks like Dirk Eddelbuettel has in > fact built what I was asking for with 'drat', > https://github.com/eddelbuettel/drat. The element that I do not see in > 'drat' is a way to build Mac and Windows binaries, so I have two follow up > questons: > (1) Has anyone extended 'drat' in this way, to create a continuous build > system, e.g. using Github to host the source of their R package and drat to > publish the binaries, with a source/Windows/MacOS build system in between?; Maybe appveyor (https://github.com/krlmlr/r-appveyor) could be of help here for the Windows part? Appveyor takes care of the continuous integration. But appveyor also allows you to define (at least some) "artifacts"; they are used regularly to download the package-name.Rcheck to examine the logs but maybe it could be tweaked to get it to produce the zip file. (Note: this is just a quick idea and my experience with appveyor is fairly limited; I use to check that some of my packages in github work in windows, so maybe this will not do what you want). Best, R. > (2) Has CRAN 'open sourced' how they build on Windows and MacOS to allow > someone to duplicate their build process? I'm familiar with Rtools, > https://cran.r-project.org/bin/windows/Rtools/installer.html, which is > certainly a key element, but is there a way to somehow clone the CRAN build > process, to have some assurance that one is building package binaries the > same way CRAN does? > > Thanks, > > Bruce Hoff > Sage Bionetworks > > > On Wed, Apr 27, 2016 at 6:37 AM, Dirk Eddelbuettel <e...@debian.org> wrote: > >> >> Bruce, >> >> As Ben and Thierry already mentioned (thanks!!) drat it pretty much >> designed >> to support that out of the box (but also supports repos elsewhere; however >> there are reasons such as gh-pages that make GitHub uniquely suited). I >> have >> some moderately strongly-held beliefs about how install_github is IMHO >> unsuitable as a _release-mechanism_ which I think of as, say, tarballs >> taken >> at author-chosen points in time rather then semi-randomly selected commits >> you may end with. And drat supports such releases. We do have a few >> examples on CRAN for mixing CRAN with external releases, and some are in >> fact >> managed by drat. We also rely on drat extensively at work for a local >> repo. >> >> When I first wrote drat about a year ago, not everybody "got it" -- so >> there >> are a bunch of vignettes, as well as my talk at useR! 2015 about. Please >> peruse, and should you have questions do come back here (or file issues at >> it >> GitHub repo). >> >> Chaers, Dirk >> >> -- >> http://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 -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [Bioc-devel] update versions for 3.3 with to deal with new testthat
On Thu, 14-04-2016, at 16:47, Kasper Daniel Hansen <kasperdanielhan...@gmail.com> wrote: > Basically (and this is true for release as well) CRAN packages gets pushed > to the build system frequently. Then, it should be updated; no question :-). > I don't know if testthat has been pushed to the devel build setup yet, > but it will happen and you will get a The release of testthat is from a few hours ago, I think. (And I am having trouble building testthat under Windows with the new tool chain as well as with appveyour with Rtools33 --e.g, https://ci.appveyor.com/project/rdiaz02/oncosimul/build/1.0.76/job/aq8nm6lu5i9hld1a) > problem. If not now, then shortly after release. > > So I recommend updating, and adding a version dependence on testthat, like > Suggests: testthat (>= 1.0.0) > > Your package might fail for a few days in devel; you'll have to wait for > testthat to be updated. Sorry, I think I was not clear: after adding a "print" it will work under both 0.11 and 1.0.0. So I made the change and updated. Best, R. > > > On Thu, Apr 14, 2016 at 9:22 AM, Ramon Diaz-Uriarte <rdia...@gmail.com> > wrote: > >> Dear All, >> >> Before doing something I shouldn't I want to make sure how to proceed: >> >> a few hours ago, a new version of testthat has been made available in CRAN >> (v. 1.0.0); this version can be more picky with statements such as >> >> expect_output(out, "some message") >> >> Now (depending on the details, which I skip here) some of those might fail >> unless we write: >> >> >> expect_output(print(out), "some message"). >> >> >> This change could lead to failures of some tests (it will for my OncoSimulR >> package). >> >> >> So my question is: will new tests of BioC 3.3 use the former testthat >> (0.11) and be frozen at that version, or should we update changes that will >> prevent failures when testthat us updated to version 1.0? I'd just go ahead >> and update, but >> >> https://www.bioconductor.org/developers/release-schedule/ >> >> indicates that we should only change code if there are show-stopper >> bugs. But whether these are show stopper bugs depends on whether testthat >> will be upgraded to 1.0 >> >> >> I am inclined to upgrade, but want to make sure that is the right course of >> action. >> >> >> Best, >> >> >> R. >> >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >>ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] update versions for 3.3 with to deal with new testthat
Thanks for the reply. Updated in the svn repo. Best, R. On Thu, 14-04-2016, at 16:46, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > The build system will automatically pick up new versions from CRAN when they > are available. So yes, packages (in both release and devel) need to be > compatible with the changes in the new testthat. > > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "bioc-devel" <bioc-devel@r-project.org> >> Cc: "ramon diaz" <ramon.d...@iib.uam.es> >> Sent: Thursday, April 14, 2016 6:22:06 AM >> Subject: [Bioc-devel] update versions for 3.3 with to deal with new testthat > >> Dear All, >> >> Before doing something I shouldn't I want to make sure how to proceed: >> >> a few hours ago, a new version of testthat has been made available in CRAN >> (v. 1.0.0); this version can be more picky with statements such as >> >> expect_output(out, "some message") >> >> Now (depending on the details, which I skip here) some of those might fail >> unless we write: >> >> >> expect_output(print(out), "some message"). >> >> >> This change could lead to failures of some tests (it will for my OncoSimulR >> package). >> >> >> So my question is: will new tests of BioC 3.3 use the former testthat >> (0.11) and be frozen at that version, or should we update changes that will >> prevent failures when testthat us updated to version 1.0? I'd just go ahead >> and update, but >> >> https://www.bioconductor.org/developers/release-schedule/ >> >> indicates that we should only change code if there are show-stopper >> bugs. But whether these are show stopper bugs depends on whether testthat >> will be upgraded to 1.0 >> >> >> I am inclined to upgrade, but want to make sure that is the right course of >> action. >> >> >> Best, >> >> >> R. >> >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] update versions for 3.3 with to deal with new testthat
Dear All, Before doing something I shouldn't I want to make sure how to proceed: a few hours ago, a new version of testthat has been made available in CRAN (v. 1.0.0); this version can be more picky with statements such as expect_output(out, "some message") Now (depending on the details, which I skip here) some of those might fail unless we write: expect_output(print(out), "some message"). This change could lead to failures of some tests (it will for my OncoSimulR package). So my question is: will new tests of BioC 3.3 use the former testthat (0.11) and be frozen at that version, or should we update changes that will prevent failures when testthat us updated to version 1.0? I'd just go ahead and update, but https://www.bioconductor.org/developers/release-schedule/ indicates that we should only change code if there are show-stopper bugs. But whether these are show stopper bugs depends on whether testthat will be upgraded to 1.0 I am inclined to upgrade, but want to make sure that is the right course of action. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] dropping perceval and petty from supported platforms
Dear All, In one of the packages I maintain, I have a .BBSoptions file with the single entry UnsupportedPlatforms: perceval, petty (because I used C++-11, etc). I understand this is no longer necessary, since those platforms are not supported anyway for 3.3 (https://github.com/Bioconductor/BBS#next-devel-bioconductor-33), and I can remove that file. Is that correct? Thanks, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] Build fails on windows: R_igraph_make_weak_ref not available: II
And on that same machine ("System type 64-bit operating system, x64-based
processor", "Edition Windows 10 Enterprise Evaluation", MSEdge
Win10 virtual machine), I can confirm R CMD build (and check) of OncoSimulR work
without problems (which also means the igraph issue is not showing there).
On Fri, 01-04-2016, at 12:31, Ramon Diaz-Uriarte <rdia...@gmail.com> wrote:
> Hi Dan,
>
> I cannot reproduce the issue on a machine that claims to be 64-bit. I run
> your two examples of igraph and graph just fine (using the 32 and 64 bit R
> executables); details and output from "version" pasted below. This is a
> virtual machine (my previous report for the 32 bit was another virtual
> machine), the one for "MSEdge on Win10" from
> https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/linux/.
>
> Windows system info shows, among others,
>
> "System type 64-bit operating system, x64-based processor"
> "Edition Windows 10 Enterprise Evaluation"
>
>
> When installing packages from source, R goes through the i386 and x64
> dance, and R version x64 reports arch as x86_64 . So it really seems to be
> a 64 bit machine. Given that, I find it strange that "version" shows "os
> mingw32" (but then, I know nothing about Windows).
>
>
>
>
>
>
> *
>> library(graph)
>> library(igraph)
>
> Attaching package: `igraph'
>
> The following objects are masked from `package:graph':
>
> degree, edges, intersection, union
>
> The following objects are masked from `package:stats':
>
> decompose, spectrum
>
> The following object is masked from `package:base':
>
> union
>
>> g1 = randomEGraph(LETTERS[1:15], edges=100)
>> graph_from_graphnel(g1)
> IGRAPH UNW- 15 100 --
> + attr: name (v/c), weight (e/n)
> + edges (vertex names):
> [1] A--L A--K A--I A--C A--O A--J A--D A--G A--B A--M A--F A--H A--E B--E
> B--D
> [16] B--N B--H B--J B--I B--C B--L B--K B--M B--F B--G B--O C--E C--N C--J
> C--D
> [31] C--F C--O C--I C--L C--G C--M C--K D--K D--H D--M D--O D--I D--E D--L
> D--G
> [46] D--N D--J D--F E--L E--H E--N E--F E--J E--K E--I E--G F--I F--G F--L
> F--O
> [61] F--H F--J F--M F--N F--K G--M G--K G--L G--N G--H G--I G--J G--O H--N
> H--I
> [76] H--M H--J H--K H--O H--L I--K I--M I--O I--N I--J I--L J--K J--O J--N
> J--M
> [91] J--L K--O K--L K--N L--M L--O L--N M--O M--N N--O
>> library(graph)
>> library(igraph)
>> g1 = randomEGraph(LETTERS[1:15], edges=100)
>> graph_from_graphnel(g1)
> IGRAPH UNW- 15 100 --
> + attr: name (v/c), weight (e/n)
> + edges (vertex names):
> [1] A--I A--D A--O A--N A--J A--F A--G A--B A--M A--L A--C A--K A--E A--H
> B--L
> [16] B--K B--C B--F B--G B--D B--H B--J B--N B--O B--M B--I B--E C--E C--L
> C--N
> [31] C--I C--M C--O C--D C--K C--H C--J C--F D--F D--I D--E D--G D--H D--K
> D--M
> [46] D--O D--L D--N D--J E--L E--F E--I E--N E--M E--H E--G E--K E--O F--L
> F--N
> [61] F--O F--H F--M F--J F--K F--I G--L G--H G--O G--N G--I G--J G--K G--M
> H--K
> [76] H--L H--M H--I H--N H--J I--M I--N I--L I--J I--O I--K J--O J--M J--K
> J--N
> [91] J--L K--M K--L K--O K--N L--N L--O L--M M--O M--N
>> example(graph_from_graphnel, run.dontrun=TRUE)
>
> grph__> ## Undirected
> grph__> g <- make_ring(10)
>
> grph__> V(g)$name <- letters[1:10]
>
> grph__> GNEL <- as_graphnel(g)
>
> grph__> g2 <- graph_from_graphnel(GNEL)
>
> grph__> g2
> IGRAPH UNW- 10 10 -- Ring graph
> + attr: name (g/c), mutual (g/l), circular (g/l), name (v/c), weight
> | (e/n)
> + edges (vertex names):
> [1] a--b a--j b--c c--d d--e e--f f--g g--h h--i i--j
>
> grph__> ## Directed
> grph__> g3 <- make_star(10, mode="in")
>
> grph__> V(g3)$name <- letters[1:10]
>
> grph__> GNEL2 <- as_graphnel(g3)
>
> grph__> g4 <- graph_from_graphnel(GNEL2)
>
> grph__> g4
> IGRAPH DNW- 10 9 -- In-star
> + attr: name (g/c), mode (g/c), center (g/n), name (v/c), weight (e/n)
> + edges (vertex names):
> [1] b->a c->a d->a e->a f->a g->a h->a i->a j->a
>
> grph__> #'
> grph__>
> grph__>
> grph__>
>> version
>_
> platform x86_64-w64-mingw32
> arch x86_64
> os mingw32
> system x86_64, mingw32
> status beta
> major 3
Re: [Bioc-devel] Build fails on windows: R_igraph_make_weak_ref not available
x names): [1] A--B A--G A--D A--O A--E A--M A--H A--F A--L A--J A--I A--K A--C A--N B--H [16] B--G B--F B--I B--E B--N B--D B--O B--C B--K B--L B--M B--J C--N C--H C--I [31] C--F C--G C--D C--K C--M C--J C--L C--O D--E D--J D--F D--I D--H D--L D--G [46] D--N D--M D--K D--O E--G E--J E--H E--O E--L E--M E--I E--F E--K E--N F--L [61] F--G F--N F--I F--J F--H F--K F--O G--M G--H G--N G--O G--J G--I G--K H--L [76] H--N H--J H--M H--O H--I H--K I--O I--M I--J I--K I--L J--O J--M J--L J--N [91] K--O K--M K--N K--L L--M L--N L--O M--N M--O N--O > example(graph_from_graphnel, run.dontrun=TRUE) grph__> ## Undirected grph__> g <- make_ring(10) grph__> V(g)$name <- letters[1:10] grph__> GNEL <- as_graphnel(g) grph__> g2 <- graph_from_graphnel(GNEL) grph__> g2 IGRAPH UNW- 10 10 -- Ring graph + attr: name (g/c), mutual (g/l), circular (g/l), name (v/c), weight | (e/n) + edges (vertex names): [1] a--b a--j b--c c--d d--e e--f f--g g--h h--i i--j grph__> ## Directed grph__> g3 <- make_star(10, mode="in") grph__> V(g3)$name <- letters[1:10] grph__> GNEL2 <- as_graphnel(g3) grph__> g4 <- graph_from_graphnel(GNEL2) grph__> g4 IGRAPH DNW- 10 9 -- In-star + attr: name (g/c), mode (g/c), center (g/n), name (v/c), weight (e/n) + edges (vertex names): [1] b->a c->a d->a e->a f->a g->a h->a i->a j->a grph__> #' grph__> grph__> grph__> > version _ platform i386-w64-mingw32 arch i386 os mingw32 system i386, mingw32 status beta major 3 minor 3.0 year 2016 month 03 day30 svn rev70404 language R version.string R version 3.3.0 beta (2016-03-30 r70404) nickname Supposedly Educational > Best, R. On Fri, 01-04-2016, at 01:20, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > I can also run the example on i386. Seems to just affect x64; let me know if > your experience is different when you try this on a 64-bit machine. > > I'll add this data point to the issue. > > > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "Dan Tenenbaum" <dtene...@fredhutch.org> >> Cc: "Luca De Sano" <l.des...@campus.unimib.it>, "bioc-devel" >> <bioc-devel@r-project.org> >> Sent: Thursday, March 31, 2016 4:13:49 PM >> Subject: Re: [Bioc-devel] Build fails on windows: R_igraph_make_weak_ref not >> available > >> Hi Dan, >> >> OncoSimulR is also afflicted by this >> (https://www.bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/moscato2-buildsrc.html). >> However, >> like Luca, I cannot reproduce the issue: I followed your instructions, and I >> was able to build (and check) the package without problem. >> >> Moreover, I can run the examples you report in the github issue without >> problems. Here is the output: >> >> >> >> >>> library(igraph) >>> g1 = randomEGraph(LETTERS[1:15], edges=100) >>> graph_from_graphnel(g1) >> IGRAPH UNW- 15 100 -- >> + attr: name (v/c), weight (e/n) >> + edges (vertex names): >> [1] A--G A--C A--H A--N A--K A--F A--L A--M A--I A--B A--O A--J A--E B--D >> [15] B--L B--H B--E B--O B--J B--G B--K B--M B--N B--F B--I B--C C--H C--I >> [29] C--M C--K C--N C--J C--E C--L C--F C--D C--G C--O D--M D--K D--N D--L >> [43] D--E D--I D--O D--J D--F D--H E--M E--G E--F E--L E--O E--I E--N E--K >> [57] E--J F--H F--N F--I F--L F--M F--G F--K F--J F--O G--L G--J G--N G--O >> [71] G--I G--H G--M G--K H--K H--O H--N H--I H--M H--J I--M I--K I--O I--J >> [85] I--L I--N J--L J--M J--N J--K J--O K--L K--M K--O K--N L--O L--M M--N >> [99] M--O N--O >>> >>> >>> library(graph) >>> library(igraph) >>> g1 = randomEGraph(LETTERS[1:15], edges=100) >>> graph_from_graphnel(g1) >> IGRAPH UNW- 15 100 -- >> + attr: name (v/c), weight (e/n) >> + edges (vertex names): >> [1] A--I A--G A--D A--J A--K A--B A--O A--M A--F A--H A--E A--N A--L B--M >> [15] B--H B--G B--N B--L B--O B--F B--I B--C B--J B--D B--E C--F C--O C--I >> [29] C--J C--L C--G C
Re: [Bioc-devel] Build fails on windows: R_igraph_make_weak_ref not available
ve found other packages with the same problem: >> >> http://bioconductor.org/checkResults/devel/bioc-LATEST/BiRewire/moscato2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/cellTree/moscato2-buildsrc.html >> http://bioconductor.org/checkResults/devel/bioc-LATEST/clipper/moscato2-buildsrc.html >> ... >> >> I can't reproduce the error. Any suggestion on how to solve this? >> >> Thanks >> >> -- >> Luca De Sano >> Research Associate >> >> Department of Informatics, Systems and Communication >> University of Milan Bicocca >> >> Institute of Biomembranes and Bioenergetics of the Italian National >> Research Council (IBBE-CNR) >> >> email: l.des...@campus.unimib.it >> PEC: luca.des...@pec.it >> >> [[alternative HTML version deleted]] >> >> ___ >> 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 -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] R-beta, windows, and Rtools version
OK, thanks. Will wait until it becomes Thursday over there :-) On Thu, 31-03-2016, at 08:22, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > There will be an answer tomorrow (Thursday Seattle time). > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "bioc-devel" <bioc-devel@r-project.org> >> Cc: "ramon diaz" <ramon.d...@iib.uam.es> >> Sent: Wednesday, March 30, 2016 11:17:17 PM >> Subject: [Bioc-devel] R-beta, windows, and Rtools version > >> Dear All, >> >> To have a local build machine as similar as possible to the one of BioC to >> check packages locally: >> >> >> 1. Will the new, upcoming builds, use the new R-beta (as in, e.g., >> https://cran.r-project.org/bin/windows/base/rtest.html) [the link is for >> Windows, but this question also applies to Linux] >> >> >> 2. Under Windows, will that R-beta be built using Rtools33 and gcc-4.9.3 or >> Rtools32 with gcc-4.6.3? (I think up to now Rtools32 was being used, based >> upon date and version of gcc ---4.6.3) >> >> >> >> Sorry if this has been explained before; I googled for it but could not >> find an answer. >> >> Thanks, >> >> >> R. >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] R-beta, windows, and Rtools version
Dear All, To have a local build machine as similar as possible to the one of BioC to check packages locally: 1. Will the new, upcoming builds, use the new R-beta (as in, e.g., https://cran.r-project.org/bin/windows/base/rtest.html) [the link is for Windows, but this question also applies to Linux] 2. Under Windows, will that R-beta be built using Rtools33 and gcc-4.9.3 or Rtools32 with gcc-4.6.3? (I think up to now Rtools32 was being used, based upon date and version of gcc ---4.6.3) Sorry if this has been explained before; I googled for it but could not find an answer. Thanks, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] package build failing in Windows with "Failed to locate the 'texi2pdf' output file"
Thanks Dan. Best, R. On Tue, 29-03-2016, at 17:03, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > This error happens once in a while. It's very hard to reproduce because of > that (which is probably why I never received a reply when reporting the issue > on R-devel), but the 'solution' is to wait until the next build report and it > will be gone. > > I just manually built your package on moscato2 and it was fine. > > Dan > > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "bioc-devel" <bioc-devel@r-project.org> >> Cc: "ramon diaz" <ramon.d...@iib.uam.es> >> Sent: Tuesday, March 29, 2016 1:34:04 AM >> Subject: [Bioc-devel] package build failing in Windows with "Failed to >> locate the 'texi2pdf' output file" > >> Dear All, >> >> I have a package, ADaCGH2, that I just noticed has failed to build in >> Windows in the latest report >> (https://www.bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/moscato2-buildsrc.html). >> The >> error is the dreaded >> >> Error in find_vignette_product(name, by = "texi2pdf", engine = engine) : >> Failed to locate the 'texi2pdf' output file (by engine 'utils::Sweave') >> for vignette >> >> >> But I just run the build and check three times on a local windows machine >> (with 3.3.0 alpha, r70387) and build and check are fine. Moreover, this >> package has not changed at all in a long time, so I do not understand why >> it should be failing now when it was not failing in previous reports >> (though I am not sure when it first started failing) and there is, in fact, >> a Windows binary for this version from the BioC page >> (https://www.bioconductor.org/packages/3.3/bioc/html/ADaCGH2.html). >> >> I am not sure how to proceed. >> >> Best, >> >> R. >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] package build failing in Windows with "Failed to locate the 'texi2pdf' output file"
Dear All, I have a package, ADaCGH2, that I just noticed has failed to build in Windows in the latest report (https://www.bioconductor.org/checkResults/devel/bioc-LATEST/ADaCGH2/moscato2-buildsrc.html). The error is the dreaded Error in find_vignette_product(name, by = "texi2pdf", engine = engine) : Failed to locate the 'texi2pdf' output file (by engine 'utils::Sweave') for vignette But I just run the build and check three times on a local windows machine (with 3.3.0 alpha, r70387) and build and check are fine. Moreover, this package has not changed at all in a long time, so I do not understand why it should be failing now when it was not failing in previous reports (though I am not sure when it first started failing) and there is, in fact, a Windows binary for this version from the BioC page (https://www.bioconductor.org/packages/3.3/bioc/html/ADaCGH2.html). I am not sure how to proceed. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] test coverage in Release packages
Hi Dan, On Tue, 20-10-2015, at 23:56, Dan Tenenbaum <dtene...@fredhutch.org> wrote: > Hi Ramon, > > - Original Message - >> From: "Ramon Diaz-Uriarte" <rdia...@gmail.com> >> To: "bioc-devel" <bioc-devel@r-project.org> >> Cc: "ramon diaz" <ramon.d...@iib.uam.es> >> Sent: Sunday, October 18, 2015 12:58:35 PM >> Subject: [Bioc-devel] test coverage in Release packages > >> Dear All, >> >> In the 3.2 release, at least some packages (e.g., my OncoSimulR, but at >> least also a few others from other maintainers I've checked) are showing >> "unknown" for the test coverage shield when those packages do really have >> tests (with coverages from 25% to 95%). >> >> It was my understanding (from https://support.bioconductor.org/p/69140/) >> that the coverage calculation was done a few times a week so I was >> expecting it to be in place a few days after the release. >> > > Thanks for letting us know about this and thanks for your patience. > There were several issues going on behind the scenes, but I think we're > sorted out now. > These coverage shields should be updated in release. > Thank you! Best, R. > Dan > > >> >> Best, >> >> >> R. >> >> >> >> -- >> Ramon Diaz-Uriarte >> Department of Biochemistry, Lab B-25 >> Facultad de Medicina >> Universidad Autónoma de Madrid >> Arzobispo Morcillo, 4 >> 28029 Madrid >> Spain >> >> Phone: +34-91-497-2412 >> >> Email: rdia...@gmail.com >> ramon.d...@iib.uam.es >> >> http://ligarto.org/rdiaz >> >> ___ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] upgrading
Dear Daniel,
I was just doing the same thing, and things worked fine for me (I am on Linux):
- download and compile R-devel
- get biocLite
source("http://bioconductor.org/biocLite.R;)
which tells me
trying URL
'https://bioconductor.org/packages/3.3/bioc/src/contrib/BiocInstaller_1.21.1.tar.gz'
(...[stuff omitted here])
Bioconductor version 3.3 (BiocInstaller 1.21.1)
- Then, I always do (since I run all of this from an automated script)
try(useDevel(devel = TRUE))
which sure enough tells me
Error : 'devel' version already in use
but things work fine, and I have installed a bunch of packages from devel.
R.
On Tue, 20-10-2015, at 16:55, Kasper Daniel Hansen
<kasperdanielhan...@gmail.com> wrote:
> So I have an R-devel where I have a previous (pre-bioc-3.2) installed
> version of BiocInstaller.
>
> 1) I re-compile R-devel today.
> 2) I run
> source("http://www.bioconductor.org/biocLite.R;)
> which gives me BiocInstaller 1.20.0. However, the current one for
> Bioc-devel is 1.21.1.
>
> When I try to push to a higher level version, by doing
> library(BiocInstaller)
> useDevel(TRUE)
> I get
>
>> useDevel(TRUE)
> Error: 'devel' version requires a more recent R
>
> If I now try to upgrade I get
>> biocLite("BiocUpgrade")
> Error: Bioconductor version 3.2 cannot be upgraded with R version 3.3.0
>
> This all looks problematic. How to I upgrade to Bioc-devel using R-devel?
> Btw. there are no instructions anymore at
> https://www.bioconductor.org/developers/how-to/useDevel/
>
> Best,
> Kasper
>
> [[alternative HTML version deleted]]
>
> _______
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] test coverage in Release packages
Dear All, In the 3.2 release, at least some packages (e.g., my OncoSimulR, but at least also a few others from other maintainers I've checked) are showing "unknown" for the test coverage shield when those packages do really have tests (with coverages from 25% to 95%). It was my understanding (from https://support.bioconductor.org/p/69140/) that the coverage calculation was done a few times a week so I was expecting it to be in place a few days after the release. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] citation in packages in devel branch
Thank you. Best, R. On Fri, 26-06-2015, at 20:03, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Ramon Diaz-Uriarte rdia...@gmail.com To: bioc-devel bioc-devel@r-project.org Cc: ramon diaz ramon.d...@iib.uam.es Sent: Friday, June 26, 2015 6:22:51 AM Subject: [Bioc-devel] citation in packages in devel branch Dear All, A package I have in devel (http://www.bioconductor.org/packages/devel/bioc/html/OncoSimulR.html) gives, in the web page, a citation information that does not match the one I get from downloading and installing the package and then running citation. The difference is that where it says . R package version 1.3.2. it should say BioConductor package version 1.99.0. (that is what I have in the CITATION file) It is like if the CITATION is stuck from several versions ago (in devel). But the rest of the info in that page does not show anything strange. Fixed now, thanks for the report. Dan Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] citation in packages in devel branch
Dear All, A package I have in devel (http://www.bioconductor.org/packages/devel/bioc/html/OncoSimulR.html) gives, in the web page, a citation information that does not match the one I get from downloading and installing the package and then running citation. The difference is that where it says . R package version 1.3.2. it should say BioConductor package version 1.99.0. (that is what I have in the CITATION file) It is like if the CITATION is stuck from several versions ago (in devel). But the rest of the info in that page does not show anything strange. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] consider running tools::compactPDF() on these files
Dear All, A package of mine is generating a NOTE about the vignette (a long 80 pages document) saying consider running tools::compactPDF() on these files (http://www.bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/zin1-checksrc.html ---yes, there is also a WARNING and it fails on Windoze; I am working on that, but I think I know how to fix those.) Anyway, the documentation for compactPDF says Support function for R CMD build --compact-vignettes. but since I upload the original Rnw, is there anything I can do with this NOTE? Googling around I do not find anything BioC related. Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] consider running tools::compactPDF() on these files
Thanks Dan. Best, R. On Thu, 18-06-2015, at 20:10, Dan Tenenbaum dtene...@fredhutch.org wrote: - Original Message - From: Ramon Diaz-Uriarte rdia...@gmail.com To: bioc-devel@r-project.org Cc: ramon diaz ramon.d...@iib.uam.es Sent: Thursday, June 18, 2015 11:00:51 AM Subject: [Bioc-devel] consider running tools::compactPDF() on these files Dear All, A package of mine is generating a NOTE about the vignette (a long 80 pages document) saying consider running tools::compactPDF() on these files (http://www.bioconductor.org/checkResults/devel/bioc-LATEST/OncoSimulR/zin1-checksrc.html ---yes, there is also a WARNING and it fails on Windoze; I am working on that, but I think I know how to fix those.) Anyway, the documentation for compactPDF says Support function for R CMD build --compact-vignettes. but since I upload the original Rnw, is there anything I can do with this NOTE? Googling around I do not find anything BioC related. I don't think there is anything _you_ can do, as our build system does not use the --compact-vignettes option with R CMD build. Maybe it should, but in any case this is not anything you need to worry about. Thanks, Dan Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] minor suggestion for BiocStyle?
On Thu, 02-10-2014, at 22:42, Hervé Pagès hpa...@fhcrc.org wrote:
Hi,
This makes a lot of sense. I also find a bit disturbing that the main
text cannot immediately be distinguished from other things like captions
or page headers (BiocStyle places the title of the vignette at the top
of each page but this header looks exactly like the main text, except
that it's horizontally aligned with the page number at the top-right
corner of the page).
Actually I am also disturbed by the way the page headers look. (But in
contrast to the suggestion for the float captions, I wasn't aware of a
quick fix).
Best,
R.
Thanks,
H.
On 09/28/2014 06:59 AM, Kasper Daniel Hansen wrote:
I think it is very reasonable to be able to easily identify that something
is a caption as opposed to main text. I have had this issue with floats in
vignettes before. What is less clear to me (because I am not a designer)
is how to best achieve this. It seems that we can use some (or all) of the
following
- different margins
- different font
- different text size
I think Andrzej example looks decent (although I would also make the
margins a bit smaller), but I don't have any strong opinions about how to
reach the overall goal of making captions distinct. I do strongly support
we do something though.
Best,
Kasper
On Sun, Sep 28, 2014 at 9:51 AM, Andrzej Oleś andrzej.o...@gmail.com
wrote:
Dear all,
please note that image captions in print (e.g. in journals like Nature,
Bioinformatics, Genomics to name only a few) are often typeset with a
slightly different, typically smaller font size. This makes them visually
distinct from the main paragraph text and gives more overall structure to
the document. It makes a difference especially in case of long multi-line
captions.
To give you an idea how a BiocStyle document with captions typeset with
smaller font and with boldface label would look like I attach the modified
DESeq2 vignette. Please compare with the regular one in devel.
Cheers,
Andrzej
On Sun, Sep 28, 2014 at 10:37 AM, Wolfgang Huber whu...@embl.de wrote:
AfaIcs everybody (incl. myself) involved in this so far is an amateur
when
it comes to graphics design and text layout.
This not to minimize the technical achievement!
Anyway, input from someone with graphics design / text layout credentials
(also privately) is welcome.
Wolfgang
Il giorno 28 Sep 2014, alle ore 00:52, Martin Morgan mtmor...@fhcrc.org
ha scritto:
On 09/27/2014 10:01 AM, Andrzej Oleś wrote:
Hi Ramon,
many thanks for your feedback an for your nice suggestion! Having more
distinctive image captions is for sure something worth considering. I
personally like the idea of having them typeset in a slightly smaller
font
and with boldface label. Additional margin seems reasonable as well.
I'm
not sure about changing the label separator, though.
If there are no objections I would be happy to incorporate this into
BiocStyle.
Because
- It seems very easy for one style to conflict with another in LaTeX
- It's 'easy' (in the LaTeX sense of the word!) for the user to add
their own customizations.
- Style is quite a personal thing
I'm not (without having looked at the changes!) in favor of this.
Martin
Best,
Andrzej
On Sat, Sep 27, 2014 at 8:51 AM, Ramon Diaz-Uriarte
rdia...@gmail.com
wrote:
Dear All,
I am now using BiocStyle for most of the latex I produce (even
non-bioc
related, such as teaching class notes) but I find that the text of
the
caption is often not distinct enough from the rest of the surrounding
text,
especially with multi-line captions.
I fix that using the caption package, with options
\usepackage[margin=10pt,font=small,labelfont=bf,
labelsep=endash]{caption}
(directly from p. 4 of the documentation).
I wonder if it might be worth to make something like this the
default.
(And
I of course understand that this falls under highly subjective
choice
and
thus user customization and is up to us to do it if we want, so
disregard
if irrelevant).
Best,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
[[alternative HTML version deleted]]
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Computational Biology / Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N.
PO Box 19024 Seattle, WA 98109
Location: Arnold Building M1 B861
Phone: (206) 667-2793
___
Bioc-devel@r-project.org mailing list
https
[Bioc-devel] minor suggestion for BiocStyle?
Dear All,
I am now using BiocStyle for most of the latex I produce (even non-bioc
related, such as teaching class notes) but I find that the text of the
caption is often not distinct enough from the rest of the surrounding text,
especially with multi-line captions.
I fix that using the caption package, with options
\usepackage[margin=10pt,font=small,labelfont=bf,
labelsep=endash]{caption}
(directly from p. 4 of the documentation).
I wonder if it might be worth to make something like this the default. (And
I of course understand that this falls under highly subjective choice and
thus user customization and is up to us to do it if we want, so disregard
if irrelevant).
Best,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] minor suggestion for BiocStyle?
On Sat, 27-09-2014, at 19:01, Andrzej Oleś andrzej.o...@gmail.com wrote:
Hi Ramon,
many thanks for your feedback an for your nice suggestion! Having more
Thank you (and all those involved with BiocStyle) for the style itself,
which is great.
distinctive image captions is for sure something worth considering. I
personally like the idea of having them typeset in a slightly smaller font
and with boldface label. Additional margin seems reasonable as well. I'm
not sure about changing the label separator, though.
Now that you point it out, I think I do prefer a colon too.
Best,
R.
If there are no objections I would be happy to incorporate this into
BiocStyle.
Best,
Andrzej
On Sat, Sep 27, 2014 at 8:51 AM, Ramon Diaz-Uriarte rdia...@gmail.com
wrote:
Dear All,
I am now using BiocStyle for most of the latex I produce (even non-bioc
related, such as teaching class notes) but I find that the text of the
caption is often not distinct enough from the rest of the surrounding text,
especially with multi-line captions.
I fix that using the caption package, with options
\usepackage[margin=10pt,font=small,labelfont=bf,
labelsep=endash]{caption}
(directly from p. 4 of the documentation).
I wonder if it might be worth to make something like this the default. (And
I of course understand that this falls under highly subjective choice and
thus user customization and is up to us to do it if we want, so disregard
if irrelevant).
Best,
R.
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
--
Ramon Diaz-Uriarte
Department of Biochemistry, Lab B-25
Facultad de Medicina
Universidad Autónoma de Madrid
Arzobispo Morcillo, 4
28029 Madrid
Spain
Phone: +34-91-497-2412
Email: rdia...@gmail.com
ramon.d...@iib.uam.es
http://ligarto.org/rdiaz
___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Rd] Writing my first CRAN vignette
On Sun, 18-05-2014, at 19:19, Dirk Eddelbuettel e...@debian.org wrote: On 18 May 2014 at 11:34, Hadley Wickham wrote: | I am intending to use Sweave. I have read the Sweave documentation and | section 1.4 of the extensions manual and apart from (a) do not use split = | TRUE (b) and include all the source components, there does not seem to be | anything CRAN specific. | | I'd strongly recommend using knitr instead - the biggest advantage is | that you can use markdown, which is substantially easier to use than | latex (and doesn't require such a massive toolchain) Markdown is very useful. And it keeps getting better -- shiny-within-markdow is / will rock very, very hard. But there are also some things that I still much prefer to be in pdf form, rather than (in however well-styled) html and browser content. And some paths in the toolchain that leads content from markdown to pdf are via latex, so you end up using latex anyway. Which isn't really that hard to install on any of the three main platforms as texlive bundles it pretty well. And more generally, a vignette is (at least to me, but also some others) To me too. But still, with knitr he can use as much latex as with Sweave. still a 'paper' -- something that strives to be something like an academic article (and occassionally even manages to get there). And for that form of written communication, I fear you will have to pry latex from my cold dead hands. :-). R. Dirk -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Bioc-devel] R and Bioconductor versions for the forthcoming release
Dear Martin, I am not sure to fully understand (or understand the consequences) mtmor...@fhcrc.org writes: Bioconductor developers: The Bioc release schedule is available http://bioconductor.org/developers/release-schedule/ A reminder that version 2.13 of Bioconductor will be released on October 15, and will work with R-3.0.2. Package authors should be testing the Bioc 'devel' version of their package with R-3.0.2 pre-release. R-3.0.2 is scheduled for release on September 25. The lack of synchrony between R and Bioc releases introduces a wrinkle. Users of R-3.0.2 (including the pre-release, which became available earlier today) using install.packages() (rather than the recommended biocLite()) will be directed toward Bioconductor 2.13 packages, so will be getting a preview of the Bioconductor release scheduled for October 15. So the recommended way (for now) to test our packages is to get any possible BioC dependencies using install.packages (after setting the repository with, say, biocinstallRepos() )? So the mechanism in http://www.bioconductor.org/developers/useDevel/ followed by biocLite() is not recommended? Unfortunately, the scheduling requirements of our own release cycle (including building annotation packages and providing fair warning for new package contributors) did not allow us to move the Bioconductor release forward. The chosen solution seemed least disruptive of the available options. Let me make sure I fully understand. a) The tests in http://www.bioconductor.org/checkResults/2.13/bioc-LATEST/ use R-3.0.1. And it will continue to do so up to October 15? b) Suppose package A depends on package B. Package B (with version as available in BioC devel, and with tests as shown in http://www.bioconductor.org/checkResults/2.13/bioc-LATEST/) is working OK with R-3.0.1. However, package B now breaks under R-3.0.2, or generates new warning (which would mean it is not acceptable for BioC). What will the developer of A get when she or he tries to install the dependencies of A? And what should the developer of A do? c) What will be the policy of BioC regarding the new notes that R-3.0.2 might generate (and that have been the source of several threads in the R-devel list in the last few weeks)? I've re-read http://www.bioconductor.org/developers/package-guidelines/ and I can only find Authors should also try to address all notes that arise during build or check. Best, R. R-3.0.2 allows for an environment variable to influence the version of Bioconductor in use, from the R NEWS file: • The default ‘version’ of Bioconductor for its packages has been changed to the upcoming 2.13, but this can be set by the environment variable R_BIOC_VERSION, e.g. in file Renviron.site. Martin Morgan, Bioconductor -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
[Bioc-devel] R-3.0.2 and vignettes that should not be built
Dear All, Suppose a package contains a vignette that is built quickly (small.Rnw) and another that takes a long time (big.Rnw). We want to provide both the source and the PDF for both, but on routine CMD build we only want to build the short one (the PDF for the long one having been pre-generated). This issue has come up before in this list and I think one suggested solution (see thread started by Kasper Daniel Hansen on 2012-06-12: https://stat.ethz.ch/pipermail/bioc-devel/2012-June/003446.html) was to: - place small.Rnw (and small.bib) under /vignettes - place big.Rnw AND big.pdf under /inst/doc When we execute(d) (as BioC does) R CMD build --keep-empty-dirs --no-resave-data source the PDF for small would be created (and placed under /inst/doc in source.tar.gz) and big.* would also be placed under /inst/doc. This has worked just fine for me up to now. Now, however, with R-3.0.2 (downloaded this morning; svn rev 63937), the build does not place big.pdf under /inst/doc in the tar.gz. Thus, we get a warning when we run CMD check Package vignette without corresponding PDF/HTML: ‘big.Rnw’ What is the recommended way of dealing with this? Should this question be moved to R-devel (I asked here because an identical question was dealt with in this list). Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel
Re: [Bioc-devel] R-3.0.2 and vignettes that should not be built
Dear Kasper, kasperdanielhan...@gmail.com writes: Small complaints about the package: I am on OS X and first I have to deal with the default of typedev on OS X to be the Cairo package which I don't Actually, I started using Cairo because ADaCGH2 ought to be able to run in headless servers without X11 and Cairo seems suited for that (Files are created without the dependence on X11). I also think I remember that some colleagues that have Macs reported problems with graphics that were removed when using Cairo (because of the creation of pngs under forking and/or MPI). have installed and then I need to install threeparttable in Tex installation. There is a lot to be said for minimal vignettes. Sure. But it was the best way I could find to include footnotes in tables. Anyway, seems like the pdf gets included when the longexamples Rnw file gets removed. Yes, but we often want BOTH the pdf and the Rnw (so users have access to the original code). Finally: sure you need the index.html in inst/doc? I do not need it, but if I don't include it, my recollection is that the index.html that was automatically generated did not include links to the PDF, source, and code of the two vignettes (which I think is due to the long.Rnw not having been processed). Best, R. Kasper On Tue, Sep 17, 2013 at 9:26 AM, Ramon Diaz-Uriarte rdia...@gmail.comwrote: Dear Kasper, kasperdanielhan...@gmail.com writes: As you describe this, this seems to be a change from the previously documented (in R-exts) behaviour in R. Let us review the new documentation and then we probably need to take it up with R-devel, but before doing so, experience suggests that doing our homework is I've done that homework to the best of my knowledge and specifically I've read the R-exts of the version I downloaded this morning. But I still cannot understand what should happen. For instance: The preferred location for the sources is the subdirectory vignettes of the source package, but pro tem for compatibility with the layout before R 2.14.0, vignette sources will be looked for in inst/doc if subdirectory vignettes does not exist or By default R CMD build will run Sweave on all Sweave vignette source files in vignettes, or pro tem if that does not exist, inst/doc (but not in sub-directories) and When R CMD build builds the vignettes, it copies these and the vignette sources from directory vignettes to inst/doc. But I do not see any explicit statement about what happens if both /inst/doc and /vignettes exist and inst/doc has a PDF. In the past it seems that, when /vignettes existed, the sources and built pdfs were copied to /inst/doc, and that /inst/doc (which might also have contained other PDFs) was what ended up in the tar.gz. Now, it seems, the PDF of the non-built vignetted (the one in /inst/doc) does not make it to /inst/doc in the tar.gz. beneficial. Is the package publicly available somewhere? That may be useful for other people. Sure, it is ADaCGH2 in BioC: http://www.bioconductor.org/packages/2.13/bioc/html/ADaCGH2.html Best, R. Kasper On Tue, Sep 17, 2013 at 7:09 AM, Ramon Diaz-Uriarte rdia...@gmail.com wrote: Dear All, Suppose a package contains a vignette that is built quickly (small.Rnw) and another that takes a long time (big.Rnw). We want to provide both the source and the PDF for both, but on routine CMD build we only want to build the short one (the PDF for the long one having been pre-generated). This issue has come up before in this list and I think one suggested solution (see thread started by Kasper Daniel Hansen on 2012-06-12: https://stat.ethz.ch/pipermail/bioc-devel/2012-June/003446.html) was to: - place small.Rnw (and small.bib) under /vignettes - place big.Rnw AND big.pdf under /inst/doc When we execute(d) (as BioC does) R CMD build --keep-empty-dirs --no-resave-data source the PDF for small would be created (and placed under /inst/doc in source.tar.gz) and big.* would also be placed under /inst/doc. This has worked just fine for me up to now. Now, however, with R-3.0.2 (downloaded this morning; svn rev 63937), the build does not place big.pdf under /inst/doc in the tar.gz. Thus, we get a warning when we run CMD check Package vignette without corresponding PDF/HTML: ‘big.Rnw’ What is the recommended way of dealing with this? Should this question be moved to R-devel (I asked here because an identical question was dealt with in this list). Best, R. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz ___ Bioc-devel@r-project.org mailing list
Re: [Rd] .Call ref card
Peter, thanks for the slides. However, I felt like Terry and I think because I am missing the big picture that I was somewhat surprised by some of the content and organization (e.g., the detail about character vectors, the usage of the tcltk package as example code). Best, R. On Thu, 22 Mar 2012 12:45:14 -0500,Terry Therneau thern...@mayo.edu wrote: On 03/22/2012 11:03 AM, peter dalgaard wrote: Don't know how useful it is any more, but back in the days, I gave this talk in Vienna http://www.ci.tuwien.ac.at/Conferences/useR-2004/Keynotes/Dalgaard.pdf Looking at it now, perhaps it moves a little too quickly into the hairy stuff. On the other hand, those were the things that I had found important to figure out at the time. At a quick glance, I didn't spot anything obviously outdated. Peter, I just looked at this, and I'd say that moved into the hairy stuff way too quickly. Much of what it covered I would never expect to use. Some I ddn't understand. Part of this of course is that slides for a talk are rarely very useful without the talker. Something simpler for the layman would be good. Terry T. -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Call ref card [was Re: R-devel Digest, Vol 109, Issue 22]
/mailman/listinfo/r-devel -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25 Facultad de Medicina Universidad Autónoma de Madrid Arzobispo Morcillo, 4 28029 Madrid Spain Phone: +34-91-497-2412 Email: rdia...@gmail.com ramon.d...@iib.uam.es http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] using zlib in a package: problems in windows
Dear Prof. Ripley, Thanks. Best, R. On Tue, May 20, 2008 at 7:44 AM, Prof Brian Ripley [EMAIL PROTECTED] wrote: gzprintf is not in Rzlib.dll. It has been commented out in the R build. So you will need to use you own copy of zlib. On Tue, 20 May 2008, Ramon Diaz-Uriarte wrote: Dear All, I am having trouble getting an R package to build and install correctly under Windows. In this package, which builds and checks OK under Linux, I use zlib (among other functions, gzprintf). As mentioned by Prof. Ripley a while back, the file CHANGES under src/gnuwin32 says explains that to, to use zlib, one has to set $(ZLIB_LIBS) in PKG_LIBS. I have a Makefile.win with just that. I have also downloaded the Windows toolset (Rtools.exe) which I have used to successfully build R-patched. However, I still cannot get the package to compile. From the log, it seems that in fact the build is trying to use zlib, but the gzprintf symbol is not found. However, gzprintf is in the zlib.h header. 00install.out follows below. What am I doing wrong? Thanks, R. P.D. I am using Windows 2000 (under vmware). -- Making package RJaCGH ** WARNING: this package has a configure script It probably needs manual configuration ** adding build stamp to DESCRIPTION installing NAMESPACE file and metadata making DLL ... making nnhl.d from nnhl.c gcc -std=gnu99 -Ic:/R/R-patc~1/include -O3 -Wall -c nnhl.c -o nnhl.o windres --preprocessor=gcc -E -xc -DRC_INVOKED -I c:/R/R-patc~1/include -i RJaCGH_res.rc -o RJaCGH_res.o gcc -std=gnu99 -shared -s -o RJaCGH.dll RJaCGH.def nnhl.o RJaCGH_res.o -Lc:/R/R-patc~1/bin -lRzlib -lR nnhl.o:nnhl.c:(.text+0x138f): undefined reference to `gzprintf' nnhl.o:nnhl.c:(.text+0x13ae): undefined reference to `gzprintf' nnhl.o:nnhl.c:(.text+0x13d2): undefined reference to `gzprintf' nnhl.o:nnhl.c:(.text+0x13f6): undefined reference to `gzprintf' nnhl.o:nnhl.c:(.text+0x1415): undefined reference to `gzprintf' nnhl.o:nnhl.c:(.text+0x1451): more undefined references to `gzprintf' follow collect2: ld returned 1 exit status make[3]: *** [RJaCGH.dll] Error 1 make[2]: *** [srcDynlib] Error 2 make[1]: *** [all] Error 2 make: *** [pkg-RJaCGH] Error 2 *** Installation of RJaCGH failed *** -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] returning vectors of unknown size from C (with .C)
On Sat, Apr 26, 2008 at 3:19 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: Ramon Diaz-Uriarte wrote: Dear All, In a package, I am using .C to call some C functions. In one case, the number of elements of the return vectors are not known in R before the C call. (Two of the vectors are integers, the third is vector of character strings). Passing from R a vector of the maximum possible size would be a huge waste. I understand one alternative is to use .Call, but I'd rather avoid it if I can (all of the code seems working except for the return of values into R). Another would be to write to a file from C and then read that into R, but this looks very ugly. Are there any other reasonable alternatives, or should I just use .Call? .Call is usually easiest, but another possibility is to have two entry points: one to calculate how much space you need, a second to pass in a vector that's the right size to hold the result. You mean making two successive calls to the C code? The problem is that the size of the result is not known until the result is obtained (in my C code, the underlying structure is a linked list that gets stretched as needed as the computation proceeds). So I would not know where to leave the result from C in between the two calls to C. Best, R. Duncan Murdoch Thanks, R. -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] returning vectors of unknown size from C (with .C)
On Sat, Apr 26, 2008 at 11:38 AM, Prof Brian Ripley [EMAIL PROTECTED] wrote: On Sat, 26 Apr 2008, Ramon Diaz-Uriarte wrote: On Sat, Apr 26, 2008 at 3:19 AM, Duncan Murdoch [EMAIL PROTECTED] wrote: Ramon Diaz-Uriarte wrote: Dear All, In a package, I am using .C to call some C functions. In one case, the number of elements of the return vectors are not known in R before the C call. (Two of the vectors are integers, the third is vector of character strings). Passing from R a vector of the maximum possible size would be a huge waste. I understand one alternative is to use .Call, but I'd rather avoid it if I can (all of the code seems working except for the return of values into R). Another would be to write to a file from C and then read that into R, but this looks very ugly. Are there any other reasonable alternatives, or should I just use .Call? .Call is usually easiest, but another possibility is to have two entry points: one to calculate how much space you need, a second to pass in a vector that's the right size to hold the result. You mean making two successive calls to the C code? The problem is that the size of the result is not known until the result is obtained (in my C code, the underlying structure is a linked list that gets stretched as needed as the computation proceeds). So I would not know where to leave the result from C in between the two calls to C. But that is possible (you malloc the memory for a local copy in the rist call), and rpart does something like it. Aha, thanks, I didn't know it was doable (or easy). I'll look at the rpart code. One further question, though, what is the rist call? Thanks, R. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] returning vectors of unknown size from C (with .C)
Dear All, In a package, I am using .C to call some C functions. In one case, the number of elements of the return vectors are not known in R before the C call. (Two of the vectors are integers, the third is vector of character strings). Passing from R a vector of the maximum possible size would be a huge waste. I understand one alternative is to use .Call, but I'd rather avoid it if I can (all of the code seems working except for the return of values into R). Another would be to write to a file from C and then read that into R, but this looks very ugly. Are there any other reasonable alternatives, or should I just use .Call? Thanks, R. -- Ramon Diaz-Uriarte Statistical Computing Team Structural Biology and Biocomputing Programme Spanish National Cancer Centre (CNIO) http://ligarto.org/rdiaz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi and OpenMPI ?
On Friday 30 March 2007 22:01, Dirk Eddelbuettel wrote:
On 30 March 2007 at 12:48, Ei-ji Nakama wrote:
| Prof. Nakano(ism Japan) and I wrestled in Rmpi on HP-MPI.
| Do not know a method to distinguish MPI well?
| It is an ad-hoc patch at that time as follows.
Thank you *very much* for this. I tried an ad-hoc patch that did about
half of this (i.e. coping with configure, and not letting zzz.R play with
lamboot) which let to Rmpi at least building ... but not yet running.
I will look more closely at what needs to happen at the C/C++ level in MPI
and see if I can (eventually) put the rest together.
As for your question about distinguishing MPI implementations: Not sure
yet. Under Debian, I had to un-install the lam and mpich2 development
packages as configure would otherwise find their mpi.h first. I'll have to
see if there is a canonical / portable identifier for MPI.
For anybody else reading along, this appears to be a great resource (and it
requires a free registration for webct):
http://webct.ncsa.uiuc.edu:8900/public/MPI/
Thanks for the link! Looks really nice indeed.
Best,
R.
Regards, Dirk
--
Ramón Díaz-Uriarte
Statistical Computing Team
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
On Monday 26 February 2007 16:51, [EMAIL PROTECTED] wrote:
First, great thanks to all for all the answers. I confess i was a bit
scared about (re)learning a possible tomorrow obsolete tool.
I'm however quite astonished nobody proposes another tool. Do 100% R
package developers use emacs ?
Plenty of folks don't use an IDE at all. Copy/pasting working bits of
code from your .Rhistory into a working file is a very useful tactic...
You kidding, right? (I mean, maybe lots of people do that, but maybe that
ain't such a good idea :-).
R.
P.S. Whether or not emacs + ess + ecb + a whole bunch of other things is or
not a real IDE (whatever that means) I think is tangential to the original
question. The issue, if I understand, are editing tools that will make the
editing et al. simpler. So
I'm however quite astonished nobody proposes another tool. Do 100% R
package developers use emacs ?
No. Not 100%. But you said you'll be using Windows but want to move to
GNU/Linux. Then, you might want to use the very same tool over a range of
OSs, or regardless of whether you are in front of your workstation, or
accessing it over a slow modem connection, etc. In such cases, Emacs is an
excellent choice. Or one of the very, very few. In addition, I think you are
seeing an example of once you try emacs, you often realize that other
choices do not really offer you all that much, but you loose a lot.
HTH,
R.
--e
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ramón Díaz-Uriarte
Statistical Computing Team
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
On Friday 23 February 2007 11:49, mel wrote:
Dear all,
I have to develop a (hopefully) small package for R in C++.
I didn't code in C++ for some years, and i'm now searching
for an adequate IDE for this task.
Some of my criterions : not proprietary, not too heavy,
open to linux, not java gasworks, still maintained, etc
After looking on several places
http://en.wikipedia.org/wiki/List_of_C%2B%2B_compilers_and_integrated_devel
opment_environments http://www.freeprogrammingresources.com/cppide.html
+ R docs
I was thinking on code::blocks, and emacs (and perhaps vim)
Emacs seems used by some R developers as an R editor.
So i did think on emacs because it could perhaps be interesting
to have the same editor for R code and C++ code.
However, when looking at the last emacs windows version,
it seems to date from january 2004 ... (dead end ?)
ftp://ftp.gnu.org/pub/gnu/emacs/windows/
I will be grateful for all advices on this tool topic.
Better choosing emacs ? or code::blocks ?
or another idea ?
Does somebody have an idea about the most used IDEs for
R C++ package writing ?
Dear Vincent,
I wouldn't let the date of 2004 scare you away from emacs. And, if I
understand, in windows you can also use xemacs and/or emacs.
One extremely nice feature of using Emacs is using the very same editor for R,
C, C++, or anything else for that matter. It certainly fits your other
requirements
Some of my criterions : not proprietary, not too heavy,
open to linux, not java gasworks, still maintained, etc
Good luck!
R.
Thanks
Vincent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ramón Díaz-Uriarte
Statistical Computing Team
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] IDE for R C++ package writing ?
On Friday 23 February 2007 15:52, Marc Schwartz wrote:
In addition to Prof. Ripley's comments, which I wholeheartedly support,
I might point you to some additional tools, that enhance the use of
Emacs for coding.
I am running Emacs (alpha version 23 from cvs source) under Linux and
while I do not do C, C++ or FORTRAN coding, these tools have
dramatically improved my coding productivity when using R and Sweave (R
+ LaTeX) along with ESS and other standard Emacs tools such as
Auctex/Preview-Latex.
1. ECB - Emacs Code Browser
http://ecb.sourceforge.net/
2. psvn - A Subversion interface for emacs
http://www.xsteve.at/prg/vc_svn/
Both of the above, especially if you integrate version control using
Subversion, greatly enhance the functionality of Emacs as an IDE.
HTH,
Marc Schwartz
Just a minor addition to Marc's comment: if you edit Python code, you might
experience short, but frequent, freezes of Emacs that are related to a
problem with semantic (a package on which ECB depends). I've not seen these
with R (or C/C++ or LaTeX).
With that minor caveat, I find ECB is a great tool that works out of the box
with R.
Best,
R.
On Fri, 2007-02-23 at 11:17 +, Prof Brian Ripley wrote:
You seem to mention both Linux and Windows.
Emacs and XEmacs are both stable on both platforms, and I think most R
developers use an emacs or vi variant for all their programming. I would
not call emacs an IDE, but the main thing I find useful is to have a
language-aware editor (syntax highlighting, indentation ...).
If you write a package you will also need an Rd editor, and emacs/ESS is
probably the best supported of those.
Later versions of precompiled emacs for Windows have existed, but I am
running 21.3.1 (2002) on Windows and 21.4.1 on Linux: emacs itself is
very stable. If you prefer a more graphical environment, XEmacs is a
good alternative and despite its name has an active Windows version.
On Fri, 23 Feb 2007, mel wrote:
Dear all,
I have to develop a (hopefully) small package for R in C++.
I didn't code in C++ for some years, and i'm now searching
for an adequate IDE for this task.
Some of my criterions : not proprietary, not too heavy,
open to linux, not java gasworks, still maintained, etc
After looking on several places
http://en.wikipedia.org/wiki/List_of_C%2B%2B_compilers_and_integrated_d
evelopment_environments
http://www.freeprogrammingresources.com/cppide.html
+ R docs
I was thinking on code::blocks, and emacs (and perhaps vim)
Emacs seems used by some R developers as an R editor.
So i did think on emacs because it could perhaps be interesting
to have the same editor for R code and C++ code.
However, when looking at the last emacs windows version,
it seems to date from january 2004 ... (dead end ?)
ftp://ftp.gnu.org/pub/gnu/emacs/windows/
I will be grateful for all advices on this tool topic.
Better choosing emacs ? or code::blocks ?
or another idea ?
Does somebody have an idea about the most used IDEs for
R C++ package writing ?
Thanks
Vincent
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ramón Díaz-Uriarte
Statistical Computing Team
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Speed of for loops
On Tuesday 30 January 2007 15:46, Tamas K Papp wrote:
On Tue, Jan 30, 2007 at 12:15:29PM +, Oleg Sklyar wrote:
magnitude using c-functions for complex vector indexing operations. If
you need instructions, I can send you a very nice Step-by-step guide
for using C/C++ in R which goes beyond Writing R Extensions document.
Hi Oleg,
Can you please post this guide online? I think that many people would
be interested in reading it, incl. me.
Me too.
Thanks,
R.
Tamas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ramón Díaz-Uriarte
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] C vs. C++ as learning and development tool for R
Dear Mark,
On Friday 19 January 2007 09:55, Kimpel, Mark William wrote:
I have 3 years of experience with R and have an interest in becoming a
better programmer so that I might someday be able to contribute
packages. Other than R, my only experience was taking Lisp from Daniel
Friedman in the 1970's. I would like to learn either C or C++ for
several reasons:
To gain a better concept of object oriented programming so that I can
begin to use S4 methods in R.
I do not think C++ is the best idea if you are learning it to understand the
OOP of R. The OOP of R is probably closer to that of CLOS (the common lisp
object system) than C++ and Java.
It might be better to directly go ahead and look for documentation specificaly
about R's OOP.
To perhaps speed up some things I do repeatedly in R
To be able to contribute a package someday.
I have been doing some reading and from what I can tell R is more
compatible with C, but C++ has much greater capabilities for OO
programming.
I have just started reading The C++ Programming Language: Special
Edition by Bjarne Stroustrup
http://search.barnesandnoble.com/booksearch/results.asp?ATH=Bjarne+Stro
ustrupz=y , he recommends first learning C++ and then then C if
necessary, but as a developer of C++, he is probably biased.
I would greatly appreciate the advice of the R developers and package
contributors on this subject. C or C++?
I'd recommend C instead of C++: C++ is a huge language and it is somewhat
easier to interface C than C++ from R. (In non-R stuff I prefer to use C++
better than C, even if just as in C++as a better C, but this probably is
not a reasonable reason to learn C++).
HTH,
R.
Thanks,
Mark
Mark W. Kimpel MD
Official Business Address:
Department of Psychiatry
Indiana University School of Medicine
PR M116
Institute of Psychiatric Research
791 Union Drive
Indianapolis, IN 46202
Preferred Mailing Address:
15032 Hunter Court
Westfield, IN 46074
(317) 490-5129 Work, Mobile
(317) 663-0513 Home (no voice mail please)
1-(317)-536-2730 FAX
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Ramón Díaz-Uriarte
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cross-compilation
Dear Tom,
It has worked for me out-of-the box in at least two times, one a while ago
with R-2.2-something and recently with R-2.4.0. In both cases, I was running
Debian (with a mix of testing and unstable) on x86. I never had to do
anything, just run the script and at least in one case I did crosscompile a
package with C++.
R.
On Wednesday 25 October 2006 18:03, Tom McCallum wrote:
Hi everyone,
I am trying to cross-compile a package I wrote using the Yan and Rossini
tutorial Building Microsoft Windows versions of R and R packages using
Intel Linux. I have got reasonably far with this but when doing the
linking using the line:
i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o
mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR
I get lots of these type of messages:
/my/path/to/mylibrary.cpp:43: undefined reference to
`_GLOBAL_OFFSET_TABLE_'
and other similar linker errors for virtually every object and command in
the program. After some googling I have found that there may be problems
with the libgcc.a library and its default -fPIC argument during
compilation.
Has anyone got this tutorial to work and if so how did they overcome this?
I am attempting to do this on Fedora Core 4 on a 32-bit machine, having
completed all the previous sections of the tutorial for building a
cross-platform version of R.
Many thanks
Tom
--
Ramón Díaz-Uriarte
Bioinformatics
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
