Re: clos mop

With mop: a local nickname for c2mop:,
I actually changed all mop: to clos: with no difference noted except for 
(mop:standard-instance-access ; <<<< not external in clos.

On 3/31/2025 3:49 PM, Daniel Kochmański wrote:
> One of the requirements is to have:
>
>  1. thread-local slots that have thread-local top-level value
>  2. thread-local slots that have shared top-level value
>
> does ContextL cater to both scenarios?
>
> N.b McCLIM already depends on closer-mop and this library uses it, so 
> I'm not sure why it does not work on LispWorks (that said I don't have 
> this implementation on my computer).
>
> Best regards,
> Daniel
>
> --
> Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland
> TurtleWare - Daniel Kochmański      | www.turtleware.eu 
> <http://www.turtleware.eu>
>
> "Be the change that you wish to see in the world." - Mahatma Gandhi
>
>
> On Monday, March 31st, 2025 at 9:43 PM, [email protected] <[email protected]> wrote:
>> Indeed, the slot access protocols in the CLOS implementation of 
>> LispWorks do not conform to the CLOS MOP standard. You could use the 
>> Closer to MOP compatibility library, which is designed to solve such 
>> compatibility issues.
>>
>> Among other things, ContextL is implemented on top of Closer to MOP, 
>> and also implements dynamically scoped slots, and a few more CLOS 
>> extensions. ContextL works very well on LispWorks. (LispWorks was 
>> actually the primary development platform for ContextL.)
>>
>> See https://github.com/pcostanza/closer-mop
>>
>> I hope this helps,
>> Pascal
>>
>>> On 31 Mar 2025, at 19:22, Paul Werkowski (as pw at snoopy dot qozzy 
>>> dot com) <[email protected]> wrote:
>>>
>>> I've known about the MOP ever since I bought Kickzales et al "The 
>>> Art of the Metaobject Protocol" in 1992 or so, and even read some of 
>>> it, but never had any opportunity to use it or even seen an example 
>>> of its use. Now I have.
>>>
>>> At https://turtleware.eu/tag/mop.html there are three articles on 
>>> Dynamic-Variables that make heavy use of the MOP. The author of 
>>> these posts, Daniel Kochmanski, aka jackdaniels, aka jd, is also the 
>>> most active contributor to the McCLIM project for the past few years 
>>> and has recently tagged the repo with its second release ,"OSTRA", 
>>> which has Dynamic-Variables integrated into its core. Apparently the 
>>> major use of DVs is to implement thread-safe drawing to screen.
>>>
>>> I've been following McCLIM development since Mike MacDonald started 
>>> it over 20 years ago and have been working on an experimental  CAPI 
>>> backend for it for a year or so.
>>>
>>> McCLIM now is entirely broken on LispWorks. The culprit appears to 
>>> be DVs. Daniel says all is well using SBCL and other open source CL 
>>> and believes something is wrong with Lispworks MOP. I have a seldom 
>>> used installation of SBCL with Emacs & Slime available. I have now 
>>> tested Dynamic-Vars.lisp (which can be downloaded from the McCLIM 
>>> repo on codeberg.org in the folder mcclim/core/system/ ) on SBCL, 
>>> and yes, work fine!
>>>
>>> I now have discovered how to get DVs working on LWW 8.1 but not 
>>> without modifying code.  See below.
>>>
>>> DVs are pretty interesting in their own right. Consider a class (as 
>>> documented in the posts)
>>>
>>> (defclass C1 ()
>>>   ((slot1 :initarg :slot1 :dynamic nil :accessor slot1)
>>>    (slot2 :initarg :slot2 :dynamic t   :accessor slot2)
>>>    (slot3 :initarg :slot3 :dynamic :tls :accessor slot3))
>>>   (:metaclass class-with-dynamic-slots))
>>>
>>> Slot3 is a thread-local-slot. An instance of C1 can be shared among 
>>> several threads with slot3 being unique to each thread. Other uses 
>>> are described in the posts.
>>> Also, according to jd, use of DV's is transparent (but not with LW).
>>>
>>> So, it appears the SBCL's implementation of C::SLOT-VALUE is 
>>> significantly different  from LW's.
>>>
>>> My work-around is to use MACROLET  to shadow cl:slot-value as shown 
>>> in the attached file. The function test-dv4 contains some portions 
>>> of a test suit (ql:quickload "mcclim/test") that now work fine when 
>>> modified using these forms.
>>>
>>> (defmacro with-dynamic-slots* (&body body)
>>>   `(macrolet ((slot-value (o s)`(dynamic-slot-value ,o ,s)))
>>>      (progn ,@body)))
>>>
>>> (defmacro with-dynamic-slots (slotnames form &body body)
>>>   `(macrolet ((slot-value (o s)`(dynamic-slot-value ,o ,s)))
>>>      (with-slots ,slotnames ,form
>>>        ,@body)))
>>>
>>> I also needed an iniitialize-instance :around method to handle 
>>> :initargs and still need to add code somewhere to add :accessor methods.
>>>
>>> I thought that LW's DEFADVICE facility might work for slot-value, 
>>> but  the manual discourages using it for low level functions. Trying 
>>> to mess with changing slot-value directly was clearly foolish!
>>>
>>> SBCL was very unhappy with me messing with shadowing its slot-value 
>>> warning loudly about violating PACKAGE-LOCK protocols.
>>>
>>> So, Common-Lisp's goal was to minimize such difference of result. 
>>> What does anyone think is going on?
>>>
>>> Paul
>>>
>>>
>>> <dv.lisp>
>>
>