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

[Aaron Lun]

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

I don't think this is really necessary; 1.7.3 will propagate soon
enough, at which point people just need to stay updated.

> Basically, before we commit changes to a class, it should not be too hard
> to assess the downstream effects and notify relevant developers.

Well, it *should* have been a transparent change (even for serialized
objects), it's just that there was a bug. This is not surprising - who
knows how many times S4Vectors has broken one of my packages - and my
attitude is to not do anything unless the fail persists in >=3 build
cycles.

-A

On Fri, Aug 2, 2019 at 9:19 AM Pages, Herve <hpages using fredhutch.org> wrote:
>
> This is a really important point.
>
> Finding and updating serialized S4 instances that are lying around
> as they evolve can be painful and very time-consuming.
>
> We should definitely avoid storing serialized S4 objects on the Hub.
> I don't know about ExperimentHub but at least for AnnotationHub I
> believe that we've been careful to avoid storing serialized S4
> instances there. The S4 objects that land on the user space are
> generally assembled on the user side from raw files downloaded from
> the Hub.
>
> H.
>
>
> On 8/2/19 02:58, Vincent Carey wrote:
> > 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 (
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_scMerge_malbec1-2Dbuildsrc.html&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=L4f9oTVSpwscJMPgdi1rNvsOuwzZZcI4el6nnCGyeIg&e= )
> >> 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://urldefense.proofpoint.com/v2/url?u=https-3A__travis-2Dci.org_SydneyBioX_scMerge_builds_566753523&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=OfWVIoa8JmqXoQPtzL6NMUEnMr3Olucnl1QXb9BdhU4&e= ), I had no
> >> errors. This file has not been edited for 2 months (
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SydneyBioX_scMerge_blob_master_vignettes_scMerge.Rmd&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=5hKxs2682qAud9bqp-7yWC6UdgioYcy3IA7xDu5tmSY&e= ).
> >>>
> >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=_iNo7wAh9O7hkrGcVDo6HLz33EINR1_3n-3VQh0wcLk&e=
> >>>
> >>
> >> _______________________________________________
> >> Bioc-devel using r-project.org mailing list
> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_bioc-2Ddevel&d=DwIFaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=YHQVNdyBX6rt3QxtsMXpCFatPq0SPNfUusESF9FXcno&s=_iNo7wAh9O7hkrGcVDo6HLz33EINR1_3n-3VQh0wcLk&e=
> >>
> >
>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpages using fredhutch.org
> Phone:  (206) 667-5791
> Fax:    (206) 667-1319