[Cuis-dev] Haver a Cuis based Smalltalk with Modules

[Gerald Klix]

Hi Chris,

On 2021-05-03 06:20, Chris Muller via Cuis-dev wrote:
> Hi Gerald,
> 
> Well, yes and no.
>>
>> Pros: It's a complete solution.
>> Cons: It's such a beast,
> 
> 
> 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.
OK.
> 
> 
>> AFIR it even features a
>> modified compiler that traps instance variable
>> access.
> 
> 
> 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?)).
I am glad, I got it all wrong ;)
> 
> 
>> There was a discussion about WriteBarriers
>> which triggered Chris Muller to respond.
>>
>>
>> http://cuis-smalltalk.org/pipermail/cuis-dev_cuis-smalltalk.org/2019-February/thread.html#4113
>>
>> some messages got cross-posted on Vm-dev, that discussion continued there:
>>
>>
>> http://lists.squeakfoundation.org/pipermail/vm-dev/2019-February/thread.html#30474
>>
>>   From that discussion I inferred porting would be
>> a real big task.
>>
> 
> 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.
> 
> 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.
So it's basically the compatibility of Squeak
and Cuis? How hard can it be?
> 
> 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.
That would be cool.
> 
> 
>> If Chris will spend some time to help me,
>> I would consider a port.
>>
> 
> I would respond to questions about Magma's design or code via email.
Thanks, Chris!
In the meantime I subscribed to Magma's mailing
list, I guess that's an option, too?
> 
>   - Chris
> 
> 

Many Thanks and Best Regards,

Gerald