<br><br><div class="gmail_quote">On Tue, Nov 29, 2011 at 11:41 PM, Juan Vuletich <span dir="ltr"><<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Mariano,<div><br>
<br>
Mariano Martinez Peck wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 ? <br>
</blockquote>
<br></div>
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.<br>
</blockquote><div><br><br>Thanks, it is much clear now. <br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While thinking about this in Fuel I asked in the mailing list <<a href="http://forum.world.st/Should-a-serializer-do-something-in-particular-with-weak-references-td3827593.html" target="_blank">http://forum.world.st/Should-<u></u>a-serializer-do-something-in-<u></u>particular-with-weak-<u></u>references-td3827593.html</a>> and the conclusion was that we shouldn't do anything special in Fuel for weak references. <br>
</blockquote>
<br>
Wrong conclusion. The correct answer was Levente's: <a href="http://forum.world.st/Should-a-serializer-do-something-in-particular-with-weak-references-td3827593.html#a3828288" target="_blank">http://forum.world.st/Should-<u></u>a-serializer-do-something-in-<u></u>particular-with-weak-<u></u>references-td3827593.html#<u></u>a3828288</a> ..<div>
<br></div></blockquote><div><br>Well, it is just "another" conclusion, but I don't think it is totally wrong (more below)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, if I understand, you are saying the opposite: do something different for weak references, basically to consider them "transient". Can you please explain me why it is needed a specific behavior for weak references?<br>
</blockquote>
<br></div>
Including objects that are only weakly referenced from within the dumped object graph (but strongly referenced from somewhere else) is useless: very shortly after materialization they will go away. You're wasting serialized file size storing garbage, and requesting that these objects can be materialized (their class or some appropriate replacement must be present, etc). </blockquote>
<div><br>100% agree. That's why I was asking, because from your first answer it looks like not doing that was WRONG or that there could be a real problem. From my point of view, it is valid, and it is a nice behavior, but it is an optimization. So I see it as an "optimized solution" :)<br>
We are probably going to do the same in Fuel.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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.<br>
<br></blockquote><div><br>I understand what you mean but I think this concrete example is wrong. Since the model doesn't know the view (hence the view is not serialized), wouldn't it always be able to be materialized in a UI-less server?<br>
<br>Thanks!<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks in advance!<br>
</blockquote>
<br>
<br>
Cheers,<span><font color="#888888"><br>
Juan Vuletich<br>
<br>
</font></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
On Sun, Nov 27, 2011 at 6:28 PM, Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a> <mailto:<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>>> wrote:<br>
<br>
Hi Folks,<br>
<br>
I found a bug in Cuis that made weak references to be improperly<br>
dumped in SmartRefStreams due to a bug in ReferenceStream. When I<br>
tried to reproduce the bug and fix in Squeak, I found out that in<br>
Squeak weak references are always dumped (and not just the more<br>
subtle bug in Cuis). The attach includes a test and fix. I'm<br>
confident about the fix in the context of Cuis, but I only played<br>
a few minutes with this in Squeak.<br>
<br>
Can anybody check this for Squeak and consider it for inclusion?<br>
<br>
Thanks,<br>
Juan Vuletich<br>
<br></div>
...<div><div><br>
<br>
<br>
!ReferenceStreamTest methodsFor: 'testing' stamp: 'jmv 11/27/2011<br>
14:56'!<br>
testWeakDumps<br>
"Test that if we serialize a model with weak references to<br>
views, only the model is serialized and not the views.<br>
<br>
Note: The bug became apparent only when dumping a model to<br>
a SmartRefStream, that calls #references, and the serialized stream<br>
was later materialized in an image where the view classes<br>
had been deleted. In such rare cases, materialization would fail<br>
when trying to reference these<br>
absent classes. If serializing to a ReferenceStream, the<br>
bug didn't become apparent (views were never serialized). If<br>
serializing to a SmartRefStream, but<br>
view classes still existed, the bug didn't really become<br>
apparent (because views were not actually deserialized), the only<br>
effect was a larger file.<br>
<br>
ReferenceStreamTest new testWeakDumps<br>
"<br>
| oldInstance refStream |<br>
oldInstance :=StringHolder new contents: 'This is a text'.<br>
oldInstance addDependent: Morph new.<br>
refStream := ReferenceStream on: (DummyStream on: nil).<br>
refStream nextPut: oldInstance.<br>
self deny: (refStream references keys anySatisfy: [<br>
:dumpedObject | dumpedObject isKindOf: Morph ])! !<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
-- <br>
Mariano<br>
<a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.<u></u>com</a><br>
</div></div></blockquote>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>