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

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

I am using a quite recent VM that Esteban provides on the JFrog bintray (debug version with symbols). So this is a bit surprising. Phil On Wed, Jan 25, 2017 at 3:41 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > @Phil, then the VM does not support it. I believe the latest VM from > files.pharo.org should support it, but not the stable one. > > @Denis Sure move it to MirrorPrimitive and update the WriteBarrier tests. > > On Wed, Jan 25, 2017 at 3:09 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-01-25 13:59 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> It also raise another question: does these primitives support mirror >>>> approach? (when it can be called with receiver as first argument?) >>>> >>> >>> Yes I made sure the mirror approach works. Even better, there are tests >>> ensuring that it works. You can see in the class WriteBarrierTest that >>> objects can become read-only through an instance of TTMirror, look for >>> example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to: >>> boolean. >>> >> >> I think we need move it to MirrorPrimitives which was introduced in Pharo >> 6. >> > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Esteban Lorenzano

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 <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] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

by phil＠highoctane.be

I am using LXC on Ubuntu to build 32 bits libraries without being bothered by the 64 bits side of things. Works nicely, especially since my user home is common to both. See https://gist.github.com/philippeback/33717128d5fb24263e557922d5ac913e Phil On Wed, Jan 25, 2017 at 3:40 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > 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 :) > With 64bit vm there will be almost none additional dependencies required. > > 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. > > 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 :) > > Cheers, > Alex >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

Norbert, On Wed, Jan 25, 2017 at 3:36 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > ClÃ©ment, > > Am 25.01.2017 um 13:54 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > > On Wed, Jan 25, 2017 at 11:35 AM, Norbert Hartl <norbert(a)hartl.name> wro > te: > >> 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. > > thank you very much for the explanation. What was the rationale behind > doing nothing as default? I can see there is two interpretations of > read-only. One being just don't modify the object the other being throwing > an exception when an attempt to modify is made. I think that having an > exception thrown would make it easier to write code using it. I don't want > to monkey patch Object but still make this general applicable. > Well, when I introduced the code I thought someone would build a ModificationTracker framework... I think there should be a modification tracker framework that throws an exception only if no program is registered to handle the modification failure. No exception should be thrown in the generic case. > > 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. > > Modification tracking is exactly the reason why I look into it. I have two > other approaches doing modification tracking. But both are inferior to an > approach using read-only objects. > 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. - add the call to the modification tracker framework from the #attemptToAssign:withIndex: call-back. - build a Modification tracker framework where external programs can easily register themselves to catch modification on specific objects or all instances of a specific class. Programs tracking modifications should be able to temporarily make the object writable, perform the modification and make it read-only again. You can check the VisualWork implementation (check for example the fall-back code of #at:put: and what it calls) and the comment I wrote in #attemptToAssign:withIndex: to get inspired. If you do something like that, please, *please*, please contribute it back to the base Pharo image. Thank you for experimenting with read-only objects. Don't hesitate to contact me if you have issues or questions. > Norbert > > 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

@Phil, then the VM does not support it. I believe the latest VM from files.pharo.org should support it, but not the stable one. @Denis Sure move it to MirrorPrimitive and update the WriteBarrier tests. On Wed, Jan 25, 2017 at 3:09 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-25 13:59 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> It also raise another question: does these primitives support mirror >>> approach? (when it can be called with receiver as first argument?) >>> >> >> Yes I made sure the mirror approach works. Even better, there are tests >> ensuring that it works. You can see in the class WriteBarrierTest that >> objects can become read-only through an instance of TTMirror, look for >> example into the users of TTMirror>>#setIsReadOnlyObjectOf: object to: >> boolean. >> > > I think we need move it to MirrorPrimitives which was introduced in Pharo > 6. >

Jan. 25, 2017

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

by Aliaksei Syrel

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 :) With 64bit vm there will be almost none additional dependencies required. 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. 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 :) Cheers, Alex

Jan. 25, 2017

Re: [Pharo-dev] Google summer of code

by Ben Coman

On Wed, Jan 25, 2017 at 4:44 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi guys, > > what I noted from the last attempts is that the Pharo proposal goes like > that: > > - here is a nice list of project ideas > > - newcomers just have to use our current set of tools for interacting and > producing code (that is > slack / mailing list / smalltalkhub / github / fogbugz / medium / etc...) > > Maybe preparing something (or planning to) a bit centralized and dedicated > to GSoC for the last point could be nice, just to explain that we're paying > attention to GSoC participants. > In the past, the GSoC participants seemed to have done their work in isolation away from the main community. I often felt the community didn't hear much from most participants. I think this is a bit adverse to the state goals of GSoC... * Help open source projects identify and bring in new developers. [1] * Help students integrate with their development community and so encourage them to become lifetime contributors [1] * During the bonding period, students are expected to get to know their project communities and participate in project discussion [1] * Get students engaged socially in the project. [2] * This is about building the STUDENTâS experience. Getting code in your project is a nice side effect. [3] Perhaps those are worth some focus in the application and project selection. [1] http://write.flossmanuals.net/gsoc-mentoring/what-is-gsoc/ [2] http://write.flossmanuals.net/gsoc-mentoring/mind-the-gap/ [3] http://write.flossmanuals.net/gsoc-mentoring/notes-for- first-year-organizations/ cheers -ben > Regards, > > Thierry > > 2017-01-25 9:21 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> Yuriy I cleaned many of the proposal >> could you do a pass on yours and keep max 4-5 of them? >> >> On Mon, Jan 23, 2017 at 5:15 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>> I can also update my projects and help with the application if needed (I >>> was a part of the application team for the last two years I think) >>> >>> Uko >>> >>> On 22 Jan 2017, at 16:33, Jigyasa Grover <grover.jigyasa1(a)gmail.com> >>> wrote: >>> >>> Also, a good application is equally important as the list of clearly >>> defined projects. >>> >>> - J >>> >>> On Sun, Jan 22, 2017 at 4:30 PM, Serge Stinckwich < >>> serge.stinckwich(a)gmail.com> wrote: >>> >>>> The list of previous projects is here: >>>> https://github.com/pharo-project/pharo-project-proposals >>>> >>>> On Sat, Jan 21, 2017 at 10:06 AM, Jigyasa Grover >>>> <grover.jigyasa1(a)gmail.com> wrote: >>>> > Dear Prof Serge >>>> > >>>> > Thanks for the introduction. >>>> > >>>> > Dear Alexandre >>>> > I have been a past Google Summer of Code student and also mentor >>>> budding >>>> > developers in Google Code-In. >>>> > This time, I was hoping to plug-in the loopholes which might have been >>>> > present in last year's organisation application. >>>> > Kindly let me know how can we collaborate further on this. >>>> > Looking forward to your response. >>>> > Thanks and Regards >>>> > Jigyasa >>>> > >>>> > >>>> > On Sat, Jan 21, 2017 at 9:06 AM, <serge.stinckwich(a)gmail.com> wrote: >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> EnvoyÃ© de mon iPhone >>>> >> Le 20 janv. 2017 Ã 22:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> a >>>> Ã©crit : >>>> >> >>>> >> What do we do? >>>> >> >>>> >> >>>> >> >>>> >> We have to apply ! ;-) >>>> >> >>>> >> We talk with Jigyasa Grover who is doing an internship in my lab at >>>> the >>>> >> moment and she is willing to help. Jigyasa was a student in a former >>>> Google >>>> >> Summer of code and is involved in several open-source initiative >>>> like Women >>>> >> who Code and FOSSASIA. She is a mentor of GoogleCodeIn. >>>> >> >>>> >> You can find a small presentation during last FOSSASIA : " >>>> >> >>>> >> My journey in FOSS with Pharo & FOSSASIA by Jigyasa Grover - FOSSASIA >>>> >> 2016" >>>> >> >>>> >> https://m.youtube.com/watch?v=uLIzylxvIz4 >>>> >> >>>> >> She has done a streaming video this morning also: >>>> http://goo.gl/UyclKP >>>> >> http://youtube.com/watch?v=2iRG_jpOL54 >>>> >> >>>> >> Anyone to help her setup a small team for Pharo proposal to Google >>>> Summer >>>> >> of Code this year ? >>>> >> >>>> >> >>>> >> On 20 Jan 2017, at 20:38, Alexandre Bergel <alexandre.bergel(a)me.com> >>>> >> wrote: >>>> >> >>>> >> Hi everyone- >>>> >> >>>> >> Google Summer of Code 2017 has officially begun! Organization >>>> applications >>>> >> open today, Thursday January 19 and are open through Thursday, >>>> February 9th. >>>> >> Please see our program site, official timeline and FAQ for more >>>> details. >>>> >> >>>> >> What makes a good organization application? Take a look at our >>>> manuals for >>>> >> tips and best practices. >>>> >> >>>> >> We look forward to seeing each of your applications and kicking off >>>> >> another great year of GSoC. If you have any questions, donât >>>> hesitate to >>>> >> reach out to gsoc-support(a)google.com. Weâre here to help! >>>> >> >>>> >> Google Open Source Programs Office >>>> >> -- >>>> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> >> Alexandre Bergel http://www.bergel.eu >>>> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> >>>> >>>> >>>> -- >>>> Serge Stinckwich >>>> UCBN & UMI UMMISCO 209 (IRD/UPMC) >>>> Every DSL ends up being Smalltalk >>>> http://www.doesnotunderstand.org/ >>>> >>>> >>> >>> >> >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Norbert Hartl

ClÃ©ment, > Am 25.01.2017 um 13:54 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > > 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. > thank you very much for the explanation. What was the rationale behind doing nothing as default? I can see there is two interpretations of read-only. One being just don't modify the object the other being throwing an exception when an attempt to modify is made. I think that having an exception thrown would make it easier to write code using it. I don't want to monkey patch Object but still make this general applicable. > 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. > Modification tracking is exactly the reason why I look into it. I have two other approaches doing modification tracking. But both are inferior to an approach using read-only objects. Norbert > 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

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60356 Home: https://github.com/pharo-project/pharo-core

Jan. 25, 2017

[pharo-project/pharo-core] a971e2: 60356

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: a971e21d0feef4294360ce08c630eb1bbdd6416f https://github.com/pharo-project/pharo-core/commit/a971e21d0feef4294360ce08… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-25 (Wed, 25 Jan 2017) Changed paths: M ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/tags/stable_.st A ConfigurationOfEpicea.package/ConfigurationOfEpicea.class/instance/versions/version807_.st M Epicea.package/EpMonitor.class/instance/announcement handling/monticelloVersionSaved_.st A Epicea.package/extension/MCCacheRepository/instance/isEpiceaCache.st A Epicea.package/extension/MCDictionaryRepository/instance/isEpiceaCache.st A Epicea.package/extension/MCRepository/instance/isEpiceaCache.st M EpiceaBrowsers.package/EpEntryItem.class/instance/converting/asMorph.st R EpiceaBrowsers.package/EpEntryItem.class/instance/operations/authorString.st A Ombu.package/OmSessionStore.class/class/initialization/initialize.st A Ombu.package/OmSessionStore.class/class/initialization/startUp.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60355.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60356.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60355.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60356.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60356 19590 Integrate new Epicea release https://pharo.fogbugz.com/f/cases/19590 http://files.pharo.org/image/60/60356.zip

Jan. 25, 2017