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

Odd (and wrong) implementation of Float>>sign

by Martin McClure

Pharo's implementation of Float>>sign is very odd, and rather disturbing. It answers 1 for positive, -1 for negative, and 0 for zero. Except for negative zero, for which it answers -1. This is asymmetric -- positive zero gets 0 but negative 0 gets -1? This does not seem correct. Both the ANSI Smalltalk spec and the ISO/IEC 10967 portable numerics spec say that "sign" should just answer 0 for zero -- positive or negative. I don't always agree with the spec, but in this case I do. The IEEE 754 floating-point spec doesn't have a "sign" operation, but it does have an operation called "isSignMinus" which can be used to distinguish negative from positive zero (and negative from positive NaN). The current implementation of #sign is self > 0 ifTrue: [^ 1]. (self < 0 or: [((self at: 1) bitShift: -31) = 1]) ifTrue: [^ -1]. ^ 0 I'd propose factoring this into two simpler methods: sign self > 0 ifTrue: [^ 1]. self < 0 ifTrue: [^ -1]. ^ 0 isSignMinus ^((self at: 1) bitShift: -31) = 1 Which would restore symmetry, as well as conforming to all the relevant specs. -Martin

Jan. 26, 2017

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

by Aliaksei Syrel

Hi, Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for fonts) + Graphite (glyphs shaping technology in order to use them within vector graphics engine) + cross platform OpenGL / Vulkan context/device provider for hardware acceleration + implement Filters for effects (blur, lights, color matrix filters, etc...). Without all those technologies bloc WILL progress, from 80's to 00's. Still decades behind :) Cheers On Jan 26, 2017 20:40, "stepharong" <stepharong(a)free.fr> wrote: > I think that instead of investigating gtk (yet another library to bind and > carry around), > it would be smarter to have Sparta back-end using an accelerated Cairo + > pango. > Why? Because > - For example Cairo will not disappear in the future (here you > will tell me that it does not have all the full > features.... I think that Bloc should deliver Brick first and > focus on this because else it will stay a nice > experiment.) > - We do not have bench with an accelerated compiled version so no > idea if this is good enough. > - Cairo is about 1.5 mb vs 20Mb and it is packaged. > > I share the concerns of Esteban about the maintenance of such Mozz2d > bundling and he was pretty > clear with me, he will not maintain it nor take any responsibility about > pharo using it. > > So having a Cairo Sparta back-end would be a smart move. > Stef > > > > > > 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/Platf >> orm/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." >> >> >> >> >> >> > > -- > Using Opera's mail client: http://www.opera.com/mail/ > >

Jan. 26, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Bernhard Pieber

Am 20.01.2017 um 14:12 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > And this is done. I just upload new stable version: > - source code shortcuts are managed by Calypso. I found simple hook how to achieve this > - senders/implementors by source code shortcuts in method browser are now opened in new tabs instead of separate window. > - no Spec text model anymore. Rubric widgets are used directly. It improves speed of building text editors This is really great. I love the Method Browser. Thank you! Bernhard

Jan. 26, 2017

Re: [Pharo-dev] [Ann] PharmIDE: Pharo remote IDE to develop farm of Pharo images remotely

by stepharong

Denis Since I'm basically the head of the team that pays you :) I would really like to have a chance to talk about the name of this environment. Because we will have to market it to a lot of people so I would like to take the time to think about a name that looks like a name. Stef > Hi. > > I am glad announce first version of PharmIDE project which is complete > toolset for remote development of Pharo images. It includes: > remote debugger > remote inspector > remote playground > remote browser > Old project RemoteDebuggingTools is deprecated. But it could be used for > Pharo 5 images. PharmIDE targets Pharo 6 or later and provides > everything which was done in original project. > > For details and live demo look at my blog > http://dionisiydk.blogspot.fr/2017/01/pharmide-pharo-remote-ide-to-develop.…. > > Best regards, > Denis -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

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

by stepharong

I think that instead of investigating gtk (yet another library to bind and carry around), it would be smarter to have Sparta back-end using an accelerated Cairo + pango. Why? Because - For example Cairo will not disappear in the future (here you will tell me that it does not have all the full features.... I think that Bloc should deliver Brick first and focus on this because else it will stay a nice experiment.) - We do not have bench with an accelerated compiled version so no idea if this is good enough. - Cairo is about 1.5 mb vs 20Mb and it is packaged. I share the concerns of Esteban about the maintenance of such Mozz2d bundling and he was pretty clear with me, he will not maintain it nor take any responsibility about pharo using it. So having a Cairo Sparta back-end would be a smart move. Stef > 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." > > > > > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Torsten Bergmann

stepharong wrote: >can we rename this selector? >asMethodConst should be at least be renamed to asConstantMethod When you use "as {something}" then "something" depicts the result of the conversion message sent to an object. Like in #asNumber or #asString which shows to what the receiver will be converted. My understanding is that in the case discussed the receiver object is NOT converted to a constant unchangeable method, so #asConstantMethod would not fit as a selector. Instead it is sent to an object that afterwards is a constant within a method (so it will not be evaluated later at runtime again) so IMHO #asMethodConstant instead of #asMethodConst would be better. Finding good names is really hardest part in programming... Thanks T.

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by stepharong

Denis can we rename this selector? asMethodConst should be at least be renamed to asConstantMethod > Hi Eliot. > > 2017-01-25 19:56 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> 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. > > #once is not the same as #memoized. #memoized returns another block > which wrap original one to perform some caching. Actually I not > understand logic behind it.But #once supposed to evaluate receiver while > #memoized creates new block. > > In Pharo 6 I pushed new method #asMethodConst. Unfortunately I was not > aware about #once from VisualWorks at this time and reviewers too. > But #asMethodConst is a bit different. It is Object method instead of > Block. And it is based on AST modification.When asMethodConst is > executed it replace executing AST-node of sender with receiver which > produce new method where full message node is replaced by result as > literal. > I put mode details here > http://dionisiydk.blogspot.fr/2016/07/magic-with-pharo-reflectivity.html. > In short you can write expressions like: >> 10 factorial asMethodConst > > -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 26, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint Friday, Jan 27

by Marcus Denker

> On 26 Jan 2017, at 14:30, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > (this is a bit lateâ¦ next will be announced earlier. I will start to put the sprints as official > events on the assoc site, too) https://association.pharo.org/event-2447196 <https://association.pharo.org/event-2447196> No idea if it makes sense to have them listed hereâ¦ Marcus

Jan. 26, 2017

[ANN] Pharo Sprint Friday, Jan 27

by Marcus Denker

(this is a bit lateâ¦ next will be announced earlier. I will start to put the sprints as official events on the assoc site, too) We will organize a Pharo sprint / Moose dojo Friday, 27 Jan, starting at 10:00am. (Local Time Paris). Goals of this sprint: - Clean issue tracker to prepare for release Pharo6 - remove Pharo6 tag from not-important cases - Check Pharo5 Issues and pending back-ports Remote Sprint ============ Remotely, you can join us on Slack. During the sprint, we will try to synchronize local and remote Pharo sprinters. Known Local Sprint meeting organised ============================== We know about just one for this sprint: Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come.

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Yuriy Tymchuk

> On 26 Jan 2017, at 00:30, phil(a)highoctane.be wrote: > > SomeClass>>#initialize > self memoize: #someMethod:andParms:. > > and bingo, automatic method memoization keyed by the objects passed. > I had a prototype called âvigorous cachingâ. It worked for methods without parameters though (http://blog.yuriy.tymch.uk/2016/02/vigorous-caching-in-pharo-or-how-i-used.… <http://blog.yuriy.tymch.uk/2016/02/vigorous-caching-in-pharo-or-how-i-used.…>)

Jan. 26, 2017