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

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

by Tudor Girba

Hi, Thanks a lot for this! Alex: would you like to take over? :) Cheers, Doru > On Jan 25, 2017, at 3:21 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2017-01-25 13:40 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 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. > > First return: moz2D prerequisites do not install cleanly on ubuntu 16.04. > > They look nice and smooth, scrolling is tuned at slow for long lists. > > It segfaults regularly when scrolling. > > 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. > > Regards, > > Thierry -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Jan. 25, 2017

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

by Thierry Goubier

2017-01-25 13:40 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 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. > First return: moz2D prerequisites do not install cleanly on ubuntu 16.04. They look nice and smooth, scrolling is tuned at slow for long lists. It segfaults regularly when scrolling. 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. Regards, Thierry

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

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] [bloc] addressing the moz2d issue

by Tudor Girba

Hi, Yes, Sparta is independent from Athens. We actually started originally from Athens with a few modifications, but that soon proved to not be feasible because Athens also has to accommodate Morphic while Bloc is being developed. Sparta has a similar structure and intent as Athens, but it differs in some essential ways: - it has local coordinates. - it offers clipping based on arbitrary shape, not only rectangle. - it is for the most part stateless which makes it more suitable for composing independent visual pieces. This one in particular influences the public API. About engaging the Moz2D community, we can work on that. Cheers, Doru > On Jan 25, 2017, at 1:52 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > 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." > > > > > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

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\ >> 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 $ 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: Inline image 1] >> >> >> 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

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\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 $ 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- > project/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: Inline image 1] > > > 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

[pharo-project/pharo-core] 3bb59c: 60355

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 3bb59c064656e99de53bfc9092a643229cee9f68 https://github.com/pharo-project/pharo-core/commit/3bb59c064656e99de53bfc90… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-01-25 (Wed, 25 Jan 2017) Changed paths: R GT-Debugger.package/GTGenericStackDebugger.class/instance/updating/updateBrowser.st M GT-Debugger.package/GTMoldableDebugger.class/instance/scripting opening/open.st A SUnit-Core.package/extension/TClassDescription/instance/isTestCase.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60354.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60355.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60354.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60355.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R Traits.package/TClassDescription.class/instance/testing/isTestCase.st Log Message: ----------- 60355 19593 TClassDescription>>#isTestCase should be in SUnit-Core https://pharo.fogbugz.com/f/cases/19593 19558 GtDebugger should not call #updateSelectionInterval in #updateBrowser https://pharo.fogbugz.com/f/cases/19558 http://files.pharo.org/image/60/60355.zip

Jan. 25, 2017

[pharo-project/pharo-core]

by GitHub

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

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

On Wed, Jan 25, 2017 at 12:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > but this is not real immutability, is like a write barrier, thatâs why > those method names were not chosen. > As Esteban mentioned, read-only objects are not immutable objects, that's why we didn't use these names. This followed a lot of discussion with many mails (read-only objects are working for a year now, so we had time to discuss) and I don't think we should discuss again this topic. > Esteban > > > On 25 Jan 2017, at 12:37, phil(a)highoctane.be wrote: > > So, beImmutable and beMutable seem pretty usable and not collision causing > IMHO. > > Phil > > On Wed, Jan 25, 2017 at 12:19 PM, Norbert Hartl <norbert(a)hartl.name> > wrote: > >> >> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <estebanlm(a)gmail.com>: >> >> >> On 25 Jan 2017, at 12:04, 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 >> >> >> yes, but #setIsReadOnlyObject: deserves a place in the podium of ugly >> names :) >> >> Absolutely. And we are a really caring community because we care so much >> about a method name of a feature that does not work :) >> >> Norbert >> >> I thought the names were going to be like beWritable/beNotWritable/isWri >> table >> which are not a lot better, but wellâ¦ >> >> Esteban >> >> >> > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

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 $ 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-project/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: Inline image 1] 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