[Bioc-devel] Build error - C stack usage is too close to the limit

[Vincent Carey]

On Thu, Aug 1, 2019 at 10:36 PM Aaron Lun <
infinite.monkeys.with.keyboards using gmail.com> wrote:

> One possibility is that this is due to a regression in
> SingleCellExperiment, caused by the altexp updates and other
> refactoring. This should be fixed in 1.7.3, you can check this for
> yourself by installing drisso/SingleCellExperiment off GitHub.
>

I can confirm this.  Would it then be appropriate for scMerge to add a
(>= 1.7.3) after its Imports: entry for SingleCellExperiment?


>
> The other moral of the story is to not use serialized high-level
> objects. Serializing basic objects is fine, but the higher up you go,
> the more fragile your code becomes to refactoring. See, for example, the
> scRNAseq data package for how to deliver a SingleCellExperiment to an R
> session without relying on serialized SingleCellExperiments.
>

I have run into this issue also.  It is convenient to serialize a high-level
object.  Breaking it down to its constituents, and assembling it, is
a lot more effort.  scRNAseq:::.create_sce shows how to reassemble for
SingleCellExperiments.

Is this a principle we want to adopt?  Avoid serializing "non-basic"
objects?
updateObject methods should help centralize the effort to managing object
designs and their implementation.

It seems it would be wise to implement this principle for any resource that
might be used by both release and devel ... even in devel we may see more
breaking changes propagating as S4 classes evolve, if objects are
serialized.
Adding validObject tests in tests/ could reduce surprises.  Helping class
maintainers know what packages have serialized fragile objects might be a
task for BiocPkgTools -- but a nontrivial one.  Maybe a BiocDevTools package
would be more appropriate.  And checking hub elements seems relevant too.

Basically, before we commit changes to a class, it should not be too hard
to assess the downstream effects and notify relevant developers.  The
alternative
of banning serialized S4 objects seems too harsh and possibly ambiguous.
On the other hand it may be necessary to ban serialized S4 in the *Hubs?




>
> -A
>
> On 8/1/19 7:14 PM, Kevin Wang wrote:
> > Hi all,
> >
> > I am getting a strange build error message for scMerge (
> http://bioconductor.org/checkResults/devel/bioc-LATEST/scMerge/malbec1-buildsrc.html)
> that reads
> >
> > + "C stack usage is too close to the limit” on Linux and Mac and
> > + "evaluation nested too deeply: infinite recursion” on Windows, when
> building the vignette file “scMerge.Rmd”.
> >
> > However, when I was building the Rmd locally and also on Travis +
> pkgdown under BioC3.10 (
> https://travis-ci.org/SydneyBioX/scMerge/builds/566753523), I had no
> errors. This file has not been edited for 2 months (
> https://github.com/SydneyBioX/scMerge/blob/master/vignettes/scMerge.Rmd).
> >
> > Any help would be appreciated.
> >
> > Thank you
> > Best Wishes
> > Kevin
> >
> > PhD Candidate
> > Faculty of Science, School of Mathematics and Statistics
> > THE UNIVERSITY OF SYDNEY
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > Bioc-devel using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> _______________________________________________
> 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 ...{{dropped:18}}