nevertheless it should be there in latests vms.
which version are you using?

Esteban 

> On 25 Jan 2017, at 15:04, p...@highoctane.be wrote:
> 
> 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 
> <mailto: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 
> <mailto:p...@highoctane.be> <p...@highoctane.be <mailto: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 
> <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 
> <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-project/pharo-vm.git 
> <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 
> <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.png>
> 
> 
> On Wed, Jan 25, 2017 at 1:54 PM, Clément Bera <bera.clem...@gmail.com 
> <mailto:bera.clem...@gmail.com>> wrote:
> 
> 
> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norb...@hartl.name 
> <mailto: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