yeah, something fishy is happening there. I will take a look.
> On 25 Jan 2017, at 18:31, p...@highoctane.be wrote:
>
> pharo-win-i386-201701151442-c50dec0.zip
>
> On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano <esteba...@gmail.com
> <mailto:esteba...@gmail.com>> wrote:
> nevertheless it should be there in latests vms.
> which version are you using?
>
> Esteban
>
>> On 25 Jan 2017, at 15:04, p...@highoctane.be <mailto: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
>>
>>
>>
>>
>
>
