[squeak-dev] [Bug][Fix] In ReferenceStream, code review request

Martin Dias tinchodias at gmail.com
Wed Nov 30 06:17:52 UTC 2011


Hello

On Tue, Nov 29, 2011 at 7:41 PM, Juan Vuletich <juan at jvuletich.org> wrote:

> Hi Mariano,
>
>
> Mariano Martinez Peck wrote:
>
>> Hi. I am not sure if I understand which is the bug and it is difficult to
>> do a clear diff. You mean that weak references should NOT be serialized ?
>>
>
> The test below documents the correct behavior. See implementors and
> senders of #nextPutWeak: in Cuis. Those methods have _very_ good comments.
> If you only dump a model, any views should not get dumped. If you dump a
> view, both view and model must be dumped. Basic View / Model separation:
> the View knows the Model, the Model doesn't know about the View. In the
> case of Morph, the owner of a morph dumped by itself should not be
> included; but the owner / submorphs relationship must be correct for all
> morphs that ultimately get dumped. The subtler bug in Cuis was in
> #references, and is also caught by this test.
>

Thnaks, now I understand Levente's answer. I figure out how to implement it
on Fuel, it should be easy.



> But a serialized model should be materializable in, for instance, an
> UI-less server, or some client with a very different UI framework, etc.
> This would enable (among many other useful things) sharing serialized
> objects between Cuis, Squeak and Pharo.
>

Sorry, let me see if I understood: You mean that as the model has
references to UI objects but they are just weak references, then
"Serializer serialize: model" should not include UI objects and thus you
can transport the model with UI-framework independence. Am I right?

Cheers,
Martín


>
>  Thanks in advance!
>>
>
>
> Cheers,
> Juan Vuletich
>
>  On Sun, Nov 27, 2011 at 6:28 PM, Juan Vuletich <juan at jvuletich.org<mailto:
>> juan at jvuletich.org>> wrote:
>>
>>    Hi Folks,
>>
>>    I found a bug in Cuis that made weak references to be improperly
>>    dumped in SmartRefStreams due to a bug in ReferenceStream. When I
>>    tried to reproduce the bug and fix in Squeak, I found out that in
>>    Squeak weak references are always dumped (and not just the more
>>    subtle bug in Cuis). The attach includes a test and fix. I'm
>>    confident about the fix in the context of Cuis, but I only played
>>    a few minutes with this in Squeak.
>>
>>    Can anybody check this for Squeak and consider it for inclusion?
>>
>>    Thanks,
>>    Juan Vuletich
>>
>>    ...
>>
>>
>>
>>    !ReferenceStreamTest methodsFor: 'testing' stamp: 'jmv 11/27/2011
>>    14:56'!
>>    testWeakDumps
>>           "Test that if we serialize a model with weak references to
>>    views, only the model is serialized and not the views.
>>
>>           Note: The bug became apparent only when dumping a model to
>>    a SmartRefStream, that calls #references, and the serialized stream
>>           was later materialized in an image where the view classes
>>    had been deleted. In such rare cases, materialization would fail
>>    when trying to reference these
>>           absent classes. If serializing to a ReferenceStream, the
>>    bug didn't become apparent (views were never serialized). If
>>    serializing to a SmartRefStream, but
>>           view classes still existed, the bug didn't really become
>>    apparent (because views were not actually deserialized), the only
>>    effect was a larger file.
>>
>>           ReferenceStreamTest new testWeakDumps
>>           "
>>           | oldInstance refStream |
>>           oldInstance :=StringHolder new contents: 'This is a text'.
>>           oldInstance addDependent: Morph new.
>>           refStream := ReferenceStream on: (DummyStream on: nil).
>>           refStream nextPut: oldInstance.
>>           self deny: (refStream references keys anySatisfy: [
>>    :dumpedObject | dumpedObject isKindOf: Morph ])! !
>>
>>
>>
>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.**com <http://marianopeck.wordpress.com>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20111130/8553e1a3/attachment.htm


More information about the Squeak-dev mailing list