Skip to content
Prev 15322 / 21312 Next

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

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

            
I can confirm this.  Would it then be appropriate for scMerge to add a
(>= 1.7.3) after its Imports: entry for SingleCellExperiment?
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?