Yea, I will try.

Thank you!

On Wed, Jul 25, 2012 at 4:24 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
> On Wed, Jul 25, 2012 at 11:55 AM, Chris Muller <ma.chris.m at gmail.com> wrote:
>>
>> I need your help Eliot.  The first time Magma reads an object from the
>> db, it compiles a new (anonymous) subclass for write-barrier behavior
>> -- so it can send #modified: to the Session when any of its inst vars
>> are changed.
>>
>> The subclass cannot add any new state so how could it know the
>> Session?  Answer - when the subclass is generated, a #writeBarrier
>> accessor is generate into which the session object is hacked into one
>> of its literal associations.  Like this:
>>
>>         installAccessingOverrides
>>                 class
>>                         compileSilently:
>>                                 'writeBarrier
>>                                         ^ Object first'
>>                         classified: 'access'.
>>                 (class methodDictionary at: #writeBarrier)
>>                         literalAt: 2
>>                         put: #Object -> (WeakArray with: barrier)
>>
>> The above is generating a #writeBarrier method on 'class' which must
>> answer the Magma session object ('barrier') so it can handle the
>> #modified: logic.
>>
>> This dreadful hack accomplishes the goal (performance) in the standard
>> VM and.. I'm sure it has for some time in Cog too but.. I'm not sure
>> when or why this started happening.  With Cog 2562 when the object
>> sent #writeBarrier, it found the integer 1004867812, and so the
>> debugger popped up with "SmallInteger DNU #first".  However, when I
>> examine the CM literals of the #writeBarrier method, the Magma session
>> is in there correctly.
>>
>> A bit later (minute or so), of just sitting there, me thinking, doing
>> nothing, then suddenly "self writeBarrier" works right there in the
>> debugger!  Initially, my doing that gave me the same error, but then,
>> without my doing _anything_ it suddenly returns the correct object we
>> stuffed in the generate method above.
>>
>> At this point I'm able to resume the application, but it shortly
>> happens again -- this time with a DIFFERENT object (a character) but,
>> once again, the CM shows the correct literal in the explorer and,
>> after a moment, "self writeBarrier" stops returning the Character and
>> starts returning the correct object.
>>
>> I thought maybe inadvertently corrupted image so built fresh but it
>> still happens every time.
>>
>> Thanks very much for any insight you can provide.
>
>
> Not sure what this is, but it could be a VM bug.  Can you work on creating a
> reproducible test case and then send me an image?
>
>>
>>
>>   - Chris
>>
>
>
>
> --
> best,
> Eliot
>