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

Re: [Pharo-dev] Immutability support

by Esteban Lorenzano

but this is not real immutability, is like a write barrier, thatâs why those method names were not chosen. 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 <mailto:norbert@hartl.name>> wrote: > >> Am 25.01.2017 um 12:16 schrieb Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> >> >>> On 25 Jan 2017, at 12:04, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> >>> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@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/isWritable >> which are not a lot better, but wellâ¦ >> >> Esteban > >

Jan. 25, 2017

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

by Tudor Girba

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

[bloc] addressing the moz2d issue

by Tudor Girba

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

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

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/ > isWritable > which are not a lot better, but wellâ¦ > > Esteban > > >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

Yes, exactly how it felt. Maybe #setImmutable would be more intention revealing. Phil On Wed, Jan 25, 2017 at 11:47 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 25.01.2017 um 11:40 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > > 2017-01-25 11:35 GMT+01:00 Norbert Hartl <norbert(a)hartl.name>: > >> ASUser new >> setIsReadOnlyObject: true >> > > And why so ugly name? Why not #isReadOnlyObject:? > > > 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 > > Norbert >

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Norbert Hartl

> 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 <mailto:dionisiydk@gmail.com>> wrote: >> >> >> 2017-01-25 12:03 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@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/isWritable > which are not a lot better, but wellâ¦ > > Esteban

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Esteban Lorenzano

> 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 <mailto:dionisiydk@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 :) I thought the names were going to be like beWritable/beNotWritable/isWritable which are not a lot better, but wellâ¦ Esteban

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

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

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-25 11:59 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > why the object suffix, everything is an object, right ? 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

Jan. 25, 2017

Re: [Pharo-dev] Immutability support

by Sven Van Caekenberghe

> On 25 Jan 2017, at 11:55, 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:. why the object suffix, everything is an object, right ? the simplest wording is often the best, unless there is a good reason for something else. > It also raise another question: does these primitives support mirror approach? (when it can be called with receiver as first argument?)

Jan. 25, 2017