[Bioc-devel] Mac ARM64 binaries available

Ramon Diaz-Uriarte rd|@z02 @end|ng |rom gm@||@com
Wed Oct 5 19:31:18 CEST 2022




On Tue, 04-October-2022, at 21:21:33, Hervé Pagès <hpages.on.github using gmail.com> 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 200000 different random seeds (under Linux, and two different versions of gcc/g++; so 400000 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
>> <stvjc using channing.harvard.edu> 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 <rdiaz02 using gmail.com> 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
>>>   <Jennifer.Wokaty using sph.cuny.edu> 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 using 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: rdiaz02 using gmail.com
>>>          r.diaz using uam.es
>>>
>>>   https://ligarto.org/rdiaz
>>>   _______________________________________________
>>>   Bioc-devel using 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: rdiaz02 using gmail.com
       r.diaz using uam.es

https://ligarto.org/rdiaz


More information about the Bioc-devel mailing list