<div dir="ltr"><div dir="ltr">Hi Gerald,</div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, yes and no.<br>
<br>
Pros: It's a complete solution.<br>
Cons: It's such a beast, </blockquote><div><br></div><div>The fact it's built in a layered set of dependent packages may contribute to its sense of beastness.  Seaside suffers from the same perception, but IIRC Magma has fewer total LoC.  But if you ignore all those dependent packages which are concerned with serialization and networking, then Magma's core itself is not all that big.  There is some corner-case code here and there so it can be used harshly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">AFIR it even features a<br>
modified compiler that traps instance variable<br>
access. </blockquote><div><br></div><div>No, it doesn't modify the compiler.  You're referring to the WriteBarrier option which simply does a neat trick of generating hidden subclasses for the users' domain upon connecting their Session.  This method of change-detection is only used if you the user specifically enables it.  It's sole purpose is to improve commit performance in production.  In the context of a port to Cuis, it could be ignored completely.  Magma has its own internal change-detection which is required and used by default -- a manual scan and compare.  The only effect would be that commit performance would not be able to be optimized until you decided how you wanted to, e.g., Eliot's VM hook, Avi's classic WriteBarrier, or something else (MethodWrappers?)).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There was a discussion about WriteBarriers<br>
which triggered Chris Muller to respond.<br>
<br>
<a href="http://cuis-smalltalk.org/pipermail/cuis-dev_cuis-smalltalk.org/2019-February/thread.html#4113" rel="noreferrer" target="_blank">http://cuis-smalltalk.org/pipermail/cuis-dev_cuis-smalltalk.org/2019-February/thread.html#4113</a><br>
<br>
some messages got cross-posted on Vm-dev, that discussion continued there:<br>
<br>
<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2019-February/thread.html#30474" rel="noreferrer" target="_blank">http://lists.squeakfoundation.org/pipermail/vm-dev/2019-February/thread.html#30474</a><br>
<br>
 From that discussion I inferred porting would be<br>
a real big task.<br></blockquote><div><br></div><div>That's unfortunate because that discussion had nothing to do with the work required to port Magma to another Smalltalk.  As mentioned above, the WriteBarrier would be the last thing you would be concerned about, only after everything else was working with the internal one first.</div><div><br></div><div>Magma is just an "app" that only uses old-school, above-the-metalayer Smalltalk code.  The most magical thing it does is #become:, and #instVarAt:put:, by the Serializer package.  It's portable to any standard Smalltalk.</div><div><br></div><div>The best part about Magma right now is its reliability.  I can use it hard.  It's a safe way to keep a persistent Squeak domain for the long-term.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If Chris will spend some time to help me,<br>
I would consider a port.<br></blockquote><div><br></div><div>I would respond to questions about Magma's design or code via email.</div><div><br></div><div> - Chris</div></div></div>