Tried it and it returns false for this Windows VM.

Phil

On Wed, Jan 25, 2017 at 2:14 PM, Clément Bera <bera.clem...@gmail.com>
wrote:

> I introduced the method #supportsWriteBarrier in Pharo 6.
>
> You can backport it if you want:
>
> VirtualMachine>>#supportsWriteBarrier
> "Answer whether the VM observes the per-object read-only flag and
> consequently
> aborts writes to inst vars of, and fails primitives that attempt to write,
> to read-only objects."
>
> ^(self parameterAt: 65)
> ifNil: [false]
> ifNotNil:
> [:param| "In older VMs this is a boolean reflecting MULTIPLE_BYTECODE_SETS"
> param isInteger "In newer VMs it is a set of integer flags, bit 1 of which
> is IMMUTABILITY"
> ifTrue: [param anyMask: 2]
> ifFalse: [false]]
>
>
>
> On Wed, Jan 25, 2017 at 2:06 PM, p...@highoctane.be <p...@highoctane.be>
> wrote:
>
>> The "latest" Windows VM I do use has no such method.
>>
>> Virtual Machine
>> ---------------
>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\
>> latestvm\pharo.exe
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> VM: 201701151442 https://github.com/pharo-project/pharo-vm.git $ Date:
>> Sun Jan 15 15:42:39 2017 +0100 $ Plugins: 201701151442
>> https://github.com/pharo-project/pharo-vm.git $
>>
>> Win32 built on Jan 15 2017 15:59:52 CUT Compiler: 5.4.0
>> VMMaker versionString VM: 201701151442 https://github.com/pharo-proje
>> ct/pharo-vm.git $ Date: Sun Jan 15 15:42:39 2017 +0100 $ Plugins:
>> 201701151442 https://github.com/pharo-project/pharo-vm.git $
>> CoInterpreter * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>> StackToRegisterMappingCogit * VMMaker.oscog-eem.2090 uuid:
>> 63a161b9-17e1-4911-a89a-1687d9ba9a1a Jan 15 2017
>>
>> [image: Inline image 1]
>>
>>
>> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera <bera.clem...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norb...@hartl.name>
>>> wrote:
>>>
>>>> Does anyone know the state of immutability support in vm and image? The
>>>> latest vm downloadable is compiled with
>>>>
>>>> IMMUTABILITY=1
>>>>
>>>> (Esteban said that). When I open a pharo6 image with this VM and do:
>>>>
>>>> ASUser new
>>>>         setIsReadOnlyObject: true;
>>>>         name: 'foo'
>>>>
>>>> with
>>>>
>>>> ASUser>>#name: arg1
>>>>         name := arg1
>>>>
>>>> I don't get an exception. Is there something missing or am I not
>>>> understanding?
>>>>
>>>
>>> Hi Norbert,
>>>
>>> Thank you very much for looking read-only objects.
>>>
>>> When mutating an instance variable, the VM triggers a call-back that by
>>> default does nothing. In your case, running your code does not raise an
>>> exception but the object should not be modified either. If you want an
>>> exception, you need to change the call-back code, i.e., the method
>>> Object>>#attemptToAssign: value withIndex: index. For example, you could
>>> write:
>>>
>>> Object>>#attemptToAssign: value withIndex: index
>>> | process |
>>> self notify: 'object changed !'.
>>> process := Processor activeProcess.
>>> [ process suspendedContext: process suspendedContext sender ] forkAt:
>>> Processor activePriority + 1.
>>> Processor yield.
>>>
>>> Then, your code should open a notification window with 'object changed',
>>> and proceeding keeps running the code without mutating the object.
>>>
>>> One needs to build a ModificationTracker framework on top of the VM
>>> support I introduced. Multiple things are required, like default behavior
>>> in this call-back and in primitive failure code. I am willing to support
>>> and help anyone willing to build such a framework, but I won't build it
>>> myself.
>>>
>>> If you have any other questions or if you find bug don't hesitate to ask
>>> further questions
>>>
>>> Best,
>>>
>>> PS: Make sure "Smalltalk vm supportsWriteBarrier" answers true in your
>>> system, if this is not the case it means the VM does not support read-only
>>> objects.
>>>
>>> Clement
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>> Norbert
>>>>
>>>
>>>
>>
>

Reply via email to