That's a great suggestion.  I did it and, so far, the issue has not
occurred.  It might be fixed, thank you!

On Wed, Dec 26, 2012 at 11:47 AM, Bob Arning <arning315 at comcast.net> wrote:
> What if, instead of substituting a new literal in the CM, you tried
> modifying the literal itself? Maybe COG would not object to that.
>
>    myDomainSubclass
>         compileSilently:
>                  'writeBarrier
>                        ^ #(foo) first first'
>         classified: 'accessing'.
>
>    ((myDomainSubclass methodDictionary at: #writeBarrier)
>        literalAt: 2) at: 1
>        put: (WeakArray with: theSession)
>
>
> On 12/26/12 12:09 PM, Chris Muller wrote:
>
> With Eliot's latest Cog things are really rocking!  But I am still
> having one issue which seems to be related to a Cog code-generation /
> timing issue.
>
> It relates to a hack that dynamically creates a subclass of a domain
> class to generate overrides of all of its methods that potentially
> change the state of the object (e.g., a write-barrier).
>
> In addition to the overriding methods, it also must generate one
> accessor method which is used to refer to a Session object, so that
> the overriding methods can notify it if, in fact, an inst-var changed.
>
> When I generate the subclass, I _cannot_ add any new inst-vars to hold
> the Session (because primChangeClassTo: requires the same physical
> shape).  So, to make the hack work at all, first I compile the
> following method to establish slots for a couple of literals:
>
>    myDomainSubclass
>         compileSilently:
>                  'writeBarrier
>                        ^ Object first'
>         classified: 'accessing'.
>
> Then slap in the Session object I want into the second slot:
>
>    (myDomainSubclass methodDictionary at: #writeBarrier)
>        literalAt: 2
>        put: #Object -> (WeakArray with: theSession)
>
> Voila!  theSession has now been hacked into the CM at literal 2.
> "Object" in the code now refers to the WeakArray holding my Session
> rather than the Object class.
>
> I wouldn't do this at all if it wasn't for the 3X improvement in
> commit performance.  However, about once or twice a day, I encounter a
> debugger which indicates, by the accessing attempt, it thinks that
> literal 2 is an Integer or a Character.  Most of the time simply
> printing "self writeBarrier" right there in the debugger produces the
> correct answer (the Session object) -- as if Cog suddenly "caught up"
> with it.
>
> Any suggestions are greatly appreciated, thank you!
>
>
>
>
>
>