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

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

Hi again. On Wed, Jan 25, 2017 at 12:04 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-25 12:03 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> I think problem that these names could be already in use by frameworks. I >> am sure #isReadOnly, #beReadOnly is used in many UI's. For example Margitte >> uses it > > > And probably Glorp > The only thing we (the VM developers) care is that we have only 2 primitives, 163 to check is an object is read-only and 164 to change the read-only property of an object. We do not want to have #beReadOnlyObject and #beWritableObject as 2 different primitives, we prefer having only one primitive to mutate the state, which is currently in the Object>>#setIsReadOnlyObject: method. The Pharo community is free to pick the names they like for their primitives. We tried to use #isReadOnly, #isWritable and #beReadOnly, but as Denis mentioned, there were conflicts with other frameworks. If you rename Object>>#attemptToAssign:withIndex:, don't forget to update the special object array with the new selector.

Jan. 25, 2017

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

by phil＠highoctane.be

I have got all of the old Pen demos. No big deal to adjust them to Bloc I think. Phil On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Nice ideas! > > What would be cool if someone else would like to try to implement any of > these. Anyone interested? > > Cheers, > Doru > > > > On Jan 25, 2017, at 11:49 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Another example is a logo turtle. > > With or without animation. > > > > Stef > > > > On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Doru > > > > I would like to see the laserGame implemented in Bloc (because it does > not need widgets). > > and it will be a real example. > > > > Stef > > > > On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > 2017-01-25 11:33 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Jan 25, 2017, at 11:19 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > Hi Doru, > > > > > > 2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > ... > > > > > > Nevertheless, it would be very cool to have people test this > assumption on old machines. I think Thierry was saying that he has an old > machine :). @Thierry? > > > > > > I have low-end systems on very recent software (chromebook on Ubuntu > 16.10, laptop on 16.04), which causes two issues: > > > - Fairly slow (shows clearly where Pharo is slow or fast) > > > - Too new (breaks some vms) > > > > > > I can be a good performance indicator, yes. > > > > Great. It would be really cool if you could give Bloc a try :). > > > > Should I just give it a try, or do you have something specific in mind I > should bench (response time, animation jitter, etc..)? > > > > Regards, > > > > Thierry > > > > > > Cheers, > > Doru > > > > > > > > > > Thierry > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

On Wed, Jan 25, 2017 at 11:55 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-25 11:47 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > >> To be honest I think #isReadOnlyObject: is worse :) isXXX is a prefix for >> testing methods. isXXX with an argument feels even more strange. I would >> rather have #beReadOnly > > > Now there is #beReadOnlyObject and #beWritableObject. Maybe for primitive > it is better to use #primReadOnlyObject:. > > 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.

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

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 Cyril Ferlicot D.

On 25/01/2017 12:59, Esteban Lorenzano wrote: > but this is not real immutability, is like a write barrier, thatâs why > those method names were not chosen. > Then why not #(des)activateWriteBarrier? > Esteban > > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Jan. 25, 2017

Re: [Pharo-dev] [bloc] addressing the moz2d issue

by Guillermo Polito

Hi Doru, First, I understand the effort you all made to make this big piece of work. I have however some questions that probably you can help with: 1) I understand Sparta is a library completely independent from Athens. But I also understand that they follow the same reasoning and general design (a general API to deal with 2D vectorial graphics with pluggable backends). - What are the differences between sparta and athens then? This is really unclear to me. Are there differences in the API? in the internal backend requirements? - In case there are many differences, What are the reasons that made you implement a complete new library and not just extend the existing one (Athens)? - or even, just make a moz2d backend for athens? 2) About moz2d. I understand how the build process you use works. But it looks a bit fragile. You mention engaging the mozilla people. I think this is really important, - either they could propose an alternative solution to what you're doing - or, if you contribute back your patches to mozilla (which I think you should), this will make your process depend less on custom-made patches - besides, creating a link between the two communities is probably worth it: people in mozilla may consider how their changes impact their users. Guille On Wed, Jan 25, 2017 at 12:41 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Thank you for the intensive set of issues you raised during the Bloc > presentation. I think it is worthwhile addressing them more thoroughly, so > let me start with the issue that seemed to have caused the most worries: > Sparta & Moz2D. > > Please keep in mind that while I am involved to some extent in Bloc, the > real credits for the current state go to Glenn and Alex. > > Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/ > Platform/GFX/Moz2D) offers an advanced backend and using it puts us on > par with the rendering speed of a web browser, which is a significant added > value over what we have now. > > However, as it was noted, it does come with a cost due to the fact that it > is not available as standalone with only the features we are interested in. > The vector graphics part is actually buildable out of the box. However, the > text support needs to be extracted out of Moz2D, and this is where the > patching scripts are used. The patches are there only for compilation > purposes and not for features and they are applied automatically. You can > see it here: > https://github.com/syrel/Moz2D > > Alex updated recently the Moz2D version and it worked without problems. Of > course, future changes in Moz2D might imply changes in this script as well, > and this implies that we will need to maintain that script. And we could > imagine applying these patches on the trunk of Moz2D to see if they work, > and we can also imagine engaging with the Moz2D owners to see if we can > find a middle ground. > > Now, letâs put this into perspective. We are currently using Athens and > the Cairo backend. While Cairo is provided as a standalone library it has > not seen significant advances since Mozzila shifted its focus towards > Moz2D. So, sticking with it might not be an ideal strategy either. > > Furthermore, just like Athens, Sparta is an abstraction that allows us to > switch the underlying backend should we need to. Until now we did not find > a cross-platform backend that is as advanced and complete as Moz2D, but > there is no reason to think that none other will appear in the future. Skia > is an alternative but it is only a vector graphic engine without text > support, so using it would imply to have another library for the text > support. > > Sparta also comes with a reasonable set of tests that is aimed at testing > the basic Moz2D functionality to make sure that the assumptions on top of > which Sparta is built are correct. > > All in all, I think that the current situation is not ideal, but there is > already enough engineering in place to actually make it work. And I > definitely think that the potential it opens is rather significant. > > And, if more people look at the scripts, we might find even better and > cheaper ways to express it. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "We cannot reach the flow of things unless we let go." > > > > > >

Jan. 25, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 25, 2017

[pharo-project/pharo-core] 3b6ae2: 60354

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3b6ae280bafad0c62a9e3abfb890a8bcc308b9d3 https://github.com/pharo-project/pharo-core/commit/3b6ae280bafad0c62a9e3abf… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-25 (Wed, 25 Jan 2017) Changed paths: R GT-Debugger.package/extension/Context/instance/outerMostContext.st R GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/allAncestors.st R GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/nextAncestors.st R GT-SpotterExtensions-Core.package/extension/MCWorkingCopy/instance/versionInfo.st A Kernel.package/Class.class/instance/accessing/definitionForNautilus.st A Kernel.package/Class.class/instance/accessing/definitionForNautilusWithSlots.st A Kernel.package/Context.class/instance/accessing/outerMostContext.st A Monticello.package/MCWorkingCopy.class/instance/accessing/allAncestors.st A Monticello.package/MCWorkingCopy.class/instance/accessing/nextAncestors.st A Monticello.package/MCWorkingCopy.class/instance/accessing/versionInfo.st R Nautilus.package/extension/Class/instance/definitionForNautilus.st R Nautilus.package/extension/Class/instance/definitionForNautilusWithSlots.st R Nautilus.package/extension/TClassDescription/instance/definitionForNautilus.st R Nautilus.package/extension/TClassDescription/instance/definitionForNautilusWithSlots.st R NautilusCommon.package/NautilusUtils.class/class/utilities/isErrorTest_.st R NautilusCommon.package/NautilusUtils.class/class/utilities/isFailedTest_.st R NautilusCommon.package/NautilusUtils.class/class/utilities/isPassedTest_.st R NautilusCommon.package/NautilusUtils.class/class/utilities/isTestMethod_.st R NautilusCommon.package/extension/CompiledMethod/instance/isErrorTest.st R NautilusCommon.package/extension/CompiledMethod/instance/isFailedTest.st R NautilusCommon.package/extension/CompiledMethod/instance/isPassedTest.st R NautilusCommon.package/extension/CompiledMethod/instance/isTestMethod.st R NautilusCommon.package/extension/RGMethodDefinition/instance/isErrorTest.st R NautilusCommon.package/extension/RGMethodDefinition/instance/isFailedTest.st R NautilusCommon.package/extension/RGMethodDefinition/instance/isPassedTest.st R NautilusCommon.package/extension/RGMethodDefinition/instance/isTestMethod.st A SUnit-Core.package/extension/CompiledMethod/instance/isErrorTest.st A SUnit-Core.package/extension/CompiledMethod/instance/isFailedTest.st A SUnit-Core.package/extension/CompiledMethod/instance/isPassedTest.st A SUnit-Core.package/extension/CompiledMethod/instance/isTestMethod.st A SUnit-Core.package/extension/RGMethodDefinition/instance/isErrorTest.st A SUnit-Core.package/extension/RGMethodDefinition/instance/isFailedTest.st A SUnit-Core.package/extension/RGMethodDefinition/instance/isPassedTest.st A SUnit-Core.package/extension/RGMethodDefinition/instance/isTestMethod.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60353.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60354.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60353.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60354.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TClassDescription.class/instance/accessing/definitionForNautilus.st A Traits.package/TClassDescription.class/instance/accessing/definitionForNautilusWithSlots.st Log Message: ----------- 60354 19596 move #outerMostContext to the KernelPackage https://pharo.fogbugz.com/f/cases/19596 19597 move #definitionForNautilus &co. to the Kernel https://pharo.fogbugz.com/f/cases/19597 19595 Protocol *GT-SpotterExtensions-Core-private in MCWorkingCopy should be moved to accessing https://pharo.fogbugz.com/f/cases/19595 19594 isTestMethods &co. should be SUnit extensions, not part of Nautilus https://pharo.fogbugz.com/f/cases/19594 http://files.pharo.org/image/60/60354.zip

Jan. 25, 2017

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

by Denis Kudriashov

2017-01-25 11:45 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > Nevertheless, it would be very cool to have people test this assumption >> on old machines. I think Thierry was saying that he has an old machine :). >> @Thierry? >> > >> > I have low-end systems on very recent software (chromebook on Ubuntu >> 16.10, laptop on 16.04), which causes two issues: >> > - Fairly slow (shows clearly where Pharo is slow or fast) >> > - Too new (breaks some vms) >> > >> > I can be a good performance indicator, yes. >> >> Great. It would be really cool if you could give Bloc a try :). >> > > Should I just give it a try, or do you have something specific in mind I > should bench (response time, animation jitter, etc..)? > Would be nice just to know your feedback about BlInfiniteLinearLayoutExamples on old machines. They provide very smooth scrolling on big lists. So it should be just visible: fast it or slow.

Jan. 25, 2017

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

by Stephane Ducasse

I think that the team should do it and take it as an exercise to document the system. I would also work on a simple application for kids for example with forms (rectangle, star, ....) that the kids can duplicate and changed. It could also be a simple application to get satisfactory from customers did you like XXXX Yes Yes a bit No a bit No With a couple of example, it will show to people that - they can do something - copy the model It would be a nice example to show how this is done in bloc. All the previous examples are based on bloc only (no brick element needed). I removed graphics from future book to free my mind and be less raging. If someone wants to try I can explain the topics. Stef On Wed, Jan 25, 2017 at 12:45 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Nice ideas! > > What would be cool if someone else would like to try to implement any of > these. Anyone interested? > > Cheers, > Doru > > > > On Jan 25, 2017, at 11:49 AM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Another example is a logo turtle. > > With or without animation. > > > > Stef > > > > On Wed, Jan 25, 2017 at 11:49 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Doru > > > > I would like to see the laserGame implemented in Bloc (because it does > not need widgets). > > and it will be a real example. > > > > Stef > > > > On Wed, Jan 25, 2017 at 11:45 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > 2017-01-25 11:33 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > > > > On Jan 25, 2017, at 11:19 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > > > > > > Hi Doru, > > > > > > 2017-01-25 10:22 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > > > ... > > > > > > Nevertheless, it would be very cool to have people test this > assumption on old machines. I think Thierry was saying that he has an old > machine :). @Thierry? > > > > > > I have low-end systems on very recent software (chromebook on Ubuntu > 16.10, laptop on 16.04), which causes two issues: > > > - Fairly slow (shows clearly where Pharo is slow or fast) > > > - Too new (breaks some vms) > > > > > > I can be a good performance indicator, yes. > > > > Great. It would be really cool if you could give Bloc a try :). > > > > Should I just give it a try, or do you have something specific in mind I > should bench (response time, animation jitter, etc..)? > > > > Regards, > > > > Thierry > > > > > > Cheers, > > Doru > > > > > > > > > > Thierry > > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > > > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "It's not how it is, it is how we see it." > > >

Jan. 25, 2017