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

[Pages, Herve]

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