January 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Immutability support

by Esteban Lorenzano

yeah, something fishy is happening there. I will take a look. > On 25 Jan 2017, at 18:31, phil(a)highoctane.be wrote: > > pharo-win-i386-201701151442-c50dec0.zip > > On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > nevertheless it should be there in latests vms. > which version are you using? > > Esteban > >> On 25 Jan 2017, at 15:04, phil(a)highoctane.be <mailto:phil@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.clement(a)gmail.com <mailto:bera.clement@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, phil(a)highoctane.be <mailto:phil@highoctane.be> <phil(a)highoctane.be <mailto:phil@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.clement(a)gmail.com <mailto:bera.clement@gmail.com>> wrote: >> >> >> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@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 >> >> >> >> > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Martin McClure

On 01/25/2017 03:59 AM, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, thatâs why > those method names were not chosen. Thank you for choosing names based on "write barrier," not the incorrect "read-only" or "immutable" (which are just things that can be done with a write barrier, but not the only useful things). Regards, -Martin

Jan. 25, 2017

memoized vs once

by Eliot Miranda

Hi Ben, via FaceBook via twitter I hear you've coined BlockClosure>>#memoized. Allow me to beg you to rename it to BlockClosure>>#once. There's a preexisting implementation of this in VisualWorks by Travis Griggs called once. I hope you agree that it's good to eliminate gratuitous incompatibilities between dialects and that "once" is an elegant name. _,,,^..^,,,_ best, Eliot

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

pharo-win-i386-201701151442-c50dec0.zip On Wed, Jan 25, 2017 at 3:57 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > nevertheless it should be there in latests vms. > which version are you using? > > Esteban > > On 25 Jan 2017, at 15:04, phil(a)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.clement(a)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, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> The "latest" Windows VM I do use has no such method. >>> >>> Virtual Machine >>> --------------- >>> C:\Users\Philippe\Dropbox\Sibelga\JiraAutomation\Pharo5.0\la >>> testvm\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.png> >>> >>> >>> On Wed, Jan 25, 2017 at 1:54 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norbert(a)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 >>>>> >>>> >>>> >>> >> > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

On Wed, Jan 25, 2017 at 4:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Another question Clement. > > I found that current method doing something strange: > > attemptToAssign: value withIndex: index > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] forkAt: > Processor activePriority + 1. > Processor yield. > "CAN'T REACH" > > > Could you comment why new process needed here? > I just check simple version with error and it works: > > attemptToAssign: value withIndex: index > ^self error: 'modification failed'. > > > Also if I will modify #contents: as "*^*contents:=newValue" then > following code is working well: > > o := ValueHolder new. > o beReadOnlyObject. > [o contents: #test] on: Error do: [:err | err resumeUnchecked: #done]. "=> > #done" > > > So I not understand the problem described in method comment. > Hi Denis, I will look into this case tomorrow, it looks like a bug. Thanks for reporting. For the Process hack, it's because the call-back was designed to return no value. It may look like it works when returning a value but you will have uncommon crashes. > 2017-01-25 16:21 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> >> 2017-01-25 15:52 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Overall, you need to: >>> - change the code of all numbered primitives mutating objects (such as >>> at:put:) so that when they fail because of a read-only object they call the >>> modification tracker framework. >>> >> >> I think it is for future. >> >> But now behaviour is just inconsistent because making object readonly >> breaks any app using it *silently*. >> Also I see that instVarAt:put: will raise error instead of skipping it. >> So two ways to modify object lead to different behavior. It's not good. >> >> My conclusion: it must be error by default. Something like this: >> >> Object>>#attemptToAssign: value withIndex: index >> (ModificationForbidden for: self at: index with: value) signal >> >> It is not fix completely inconsistence with #instVarAt:put: but at least >> they both will fail. >> >> By the way I was supprized that failed #instVarAt:put: shows "bad >> receiver" in primitive *er* variable (<primitive: 174 error: *ec*>). Is >> "bad receiver" is always about mutability? And if not then how we will >> distinguish different cases? >> > >

Jan. 25, 2017

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

by Thierry Goubier

2017-01-25 16:34 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > On 25 January 2017 at 16:02, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: > >> Yes, it goes a bit faster. But I stopped half way through the list: it is >> tuned a lot slower than I'm used to with Morphic. > > > Hehe :) Tuning is another story. Current implementation treats mouse wheel > and trackpad in the same way, which should not be the case of course. > And you have to account a possible tuning for a touch screen as well... I've made my tuning for the trackpad of my two laptops, more or less (a bit oversensitive for the trackpad, but that makes the scrollwheel usable). > > Basically, If I compare the bloc class list to a Morphic class list >> scrolling variable speed example, I really have to work out hard the scroll >> wheel with Bloc... and, still, I'm not reaching the end of the list. > > > I made a video comparison of 3 list implementations that display all > smalltalk classes. I tried to scroll identically for all three cases and > covered almost the same distance with mouse wheel: > â > Morphic-Bloc-Lists.mov > <https://drive.google.com/file/d/0B-bMBVDOi3oTS1JqM01CY21PUmc/view?usp=drive…> > â > What morphic example did you use? > AltListTests exampleTree1. I'll try to show you side by side (but do I have a scroll wheel at home? Not sure). I've made a few irregular examples to test (20000 items, with a random text size from small to very large). Illustrates mostly how slow is subpixel display of text in Morphic. > I would be also very very glad to know what DNUs and segfaults you get :) > DNU is: Instance of BlSDLEventHandler did not understand #bitOr: (note, this is the user version of Bloc, not the developer one) Regards, Thierry > > > Cheers, > Alex >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

Another question Clement. I found that current method doing something strange: attemptToAssign: value withIndex: index process := Processor activeProcess. [ process suspendedContext: process suspendedContext sender ] forkAt: Processor activePriority + 1. Processor yield. "CAN'T REACH" Could you comment why new process needed here? I just check simple version with error and it works: attemptToAssign: value withIndex: index ^self error: 'modification failed'. Also if I will modify #contents: as "*^*contents:=newValue" then following code is working well: o := ValueHolder new. o beReadOnlyObject. [o contents: #test] on: Error do: [:err | err resumeUnchecked: #done]. "=> #done" So I not understand the problem described in method comment. 2017-01-25 16:21 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-01-25 15:52 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Overall, you need to: >> - change the code of all numbered primitives mutating objects (such as >> at:put:) so that when they fail because of a read-only object they call the >> modification tracker framework. >> > > I think it is for future. > > But now behaviour is just inconsistent because making object readonly > breaks any app using it *silently*. > Also I see that instVarAt:put: will raise error instead of skipping it. So > two ways to modify object lead to different behavior. It's not good. > > My conclusion: it must be error by default. Something like this: > > Object>>#attemptToAssign: value withIndex: index > (ModificationForbidden for: self at: index with: value) signal > > It is not fix completely inconsistence with #instVarAt:put: but at least > they both will fail. > > By the way I was supprized that failed #instVarAt:put: shows "bad > receiver" in primitive *er* variable (<primitive: 174 error: *ec*>). Is > "bad receiver" is always about mutability? And if not then how we will > distinguish different cases? >

Jan. 25, 2017

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

by Aliaksei Syrel

On 25 January 2017 at 16:02, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Yes, it goes a bit faster. But I stopped half way through the list: it is > tuned a lot slower than I'm used to with Morphic. Hehe :) Tuning is another story. Current implementation treats mouse wheel and trackpad in the same way, which should not be the case of course. Basically, If I compare the bloc class list to a Morphic class list > scrolling variable speed example, I really have to work out hard the scroll > wheel with Bloc... and, still, I'm not reaching the end of the list. I made a video comparison of 3 list implementations that display all smalltalk classes. I tried to scroll identically for all three cases and covered almost the same distance with mouse wheel: â Morphic-Bloc-Lists.mov <https://drive.google.com/file/d/0B-bMBVDOi3oTS1JqM01CY21PUmc/view?usp=drive…> â What morphic example did you use? I would be also very very glad to know what DNUs and segfaults you get :) Cheers, Alex

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-25 15:52 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Overall, you need to: > - change the code of all numbered primitives mutating objects (such as > at:put:) so that when they fail because of a read-only object they call the > modification tracker framework. > I think it is for future. But now behaviour is just inconsistent because making object readonly breaks any app using it *silently*. Also I see that instVarAt:put: will raise error instead of skipping it. So two ways to modify object lead to different behavior. It's not good. My conclusion: it must be error by default. Something like this: Object>>#attemptToAssign: value withIndex: index (ModificationForbidden for: self at: index with: value) signal It is not fix completely inconsistence with #instVarAt:put: but at least they both will fail. By the way I was supprized that failed #instVarAt:put: shows "bad receiver" in primitive *er* variable (<primitive: 174 error: *ec*>). Is "bad receiver" is always about mutability? And if not then how we will distinguish different cases?

Jan. 25, 2017

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

by Thierry Goubier

Hi Alex, it's good to see widget development. 2017-01-25 15:40 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > Hi Thierry > > Thanks for your testing effort! > > moz2D prerequisites do not install cleanly on ubuntu 16.04. > > Exactly, it is hard to install many 32 dependencies on 64bit linux system. > (there is no solution for this). That is why it would be nice to have 64 > bit VM for 64 bit linux :) > Yes. This is the reason I gave up on libcgit when I started GitFileTree: too complex, no :i386 system lib available. > With 64bit vm there will be almost none additional dependencies required. > Almost is the key... Given that the 64bits VM doesn't work properly on Ubuntu 16.04 and 16.10, take that as a long term goal. > > They look nice and smooth, scrolling is tuned at slow for long lists. > > How do you scroll? Current scrolling behaviour is very simple while being > rather powerful. Speed increases if user continuously scrolls with mouse > wheel or touchpad. Faster you move your finger on touchpad or scroll more > frequent with mouse wheel than faster is scrolling speed. > Ok, I tried again because I could not feel the acceleration effect. Yes, it goes a bit faster. But I stopped half way through the list: it is tuned a lot slower than I'm used to with Morphic. Reversing scrolling direction halts it immediately or slows it down? I could not see. Slow it down almost immediately (tried with the trackpad). > > It segfaults regularly when scrolling. > > This might be unrelated to the library. Could you send crash dump? > > Do you have an example of scrolling where I can choose to scroll fast or >> slow depending on how I use the trackpad or scrollwheel? On Linux, the OS >> doesn't manipulate those events as Macs seems to be doing, so you need to >> code that. > > > This behaviour is a default one. Maybe problem is with SDL2 events? Video > would be great to understand how you scroll and how you expect it to be :) > I'll try that on a lower-end machine. Basically, If I compare the bloc class list to a Morphic class list scrolling variable speed example, I really have to work out hard the scroll wheel with Bloc... and, still, I'm not reaching the end of the list. Works better with the track pad (reached the end, yes!) and had many DNUs. Segfaults if I quit the image with a bloc window open. Regards, Thierry > Cheers, > Alex >

Jan. 25, 2017