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

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

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

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

--
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 at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319