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

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by werner kassens

Hi, i wonder what is the reasoning that "Float nan sign" returns anything else than Float nan? werner On 01/26/2017 09:47 PM, Nicolas Cellier wrote: > > > 2017-01-26 21:22 GMT+01:00 Martin McClure <martin(a)hand2mouse.com > <mailto:martin@hand2mouse.com>>: > > 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. > > OK, I think you are right > > 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 > > > maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard > tells it should be 0 too? > > > isSignMinus > ^((self at: 1) bitShift: -31) = 1 > > Which would restore symmetry, as well as conforming to all the > relevant > specs. > > -Martin > > > Or just > > signBit > ^(self at: 1) bitShift: -31) > > That means that we'd have to refactor most (all?) senders of sign... >

Jan. 26, 2017

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

by phil＠highoctane.be

Moz2D looks pretty great and the stateless argument makes sense. Furthermore there is an isolation layer. Interesting reads: https://blog.mozilla.org/joe/2011/04/26/introducing-the-azure-project/ http://robert.ocallahan.org/2011/09/graphics-api-design.html https://wiki.mozilla.org/Platform/GFX/Moz2D https://dxr.mozilla.org/mozilla-central/source/gfx/2d/2D.h Having browser grade speed views in a OSWindow is enabling. Cairo is not going to give us super speedy UIs, sorry, just check the demos we have in the image, they are sluggish. Phil On Thu, Jan 26, 2017 at 10:27 PM, stepharong <stepharong(a)free.fr> wrote: > > > Hi, > > Then we will need Cairo + SDL2 (that does not work for us) > > > I do not get why SDL20 would not work for us while it is used by gaming > engines. Are we that special? > We built interactive applications for Thales with complex event touch and > now suddenly "it does not work for us" TM. > I have the impression that each time I see Bloc we need something more > special (now this is Gtk) > To me it looks like it is a systematic "fuite en avant" with even more Mb > consumption each time. > > Personally I do not care of blur and effects, or color max filters. Right > now you do not even have a single example of something that is not a little > demo. > > Why we cannot have a tk/tcl or red-language like working system? I mean > working now and not relying > on multiple MB of code extracted from an existing project? > > + 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 :) > > > Well I would prefer to have something from the 00 working now that from > 2016 not working. > > Because now what I will do is continuing to work on Morphic because this > is what I have. > You see I removed graphics from my future books. You probably do not care. > In the future I will concentrate on anything else than graphics and > widgets like that I will have no frustration. > Hacking the compiler finally should be a lot nicer. > You see next week I go to visit alain and I will not discuss nor work on > such topics like that no frustration. > > Finally I will not comment anymore on Bloc anymore. I should not have. > You do not seem to understand my point so I will shut up but years will > pass before Bloc will be integrated in Pharo, because > integrated means maintained by us in case the guys behind bloc/brick get > hired by anybody else on earth. > > > You seem to underestimate that part. > Ok you are super right and I'm super wrong. > > Stef > > > >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by phil＠highoctane.be

Guess the method is wrong given the comment. Shouldn't it be [param anyMask: 1] instead of [param anyMask: 2] ? 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. 26, 2017

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

by Tudor Girba

Hi Stef, There was a misunderstanding. Alex was just listing the need of underlying technologies for the features that Bloc already supports. Letâs restart this conversation. He will send an explanatory email. Cheers, Doru > On Jan 26, 2017, at 10:27 PM, stepharong <stepharong(a)free.fr> wrote: > > > > Hi, > > Then we will need Cairo + SDL2 (that does not work for us) > > I do not get why SDL20 would not work for us while it is used by gaming engines. Are we that special? > We built interactive applications for Thales with complex event touch and now suddenly "it does not work for us" TM. > I have the impression that each time I see Bloc we need something more special (now this is Gtk) > To me it looks like it is a systematic "fuite en avant" with even more Mb consumption each time. > > Personally I do not care of blur and effects, or color max filters. Right now you do not even have a single example of something that is not a little > demo. > > Why we cannot have a tk/tcl or red-language like working system? I mean working now and not relying > on multiple MB of code extracted from an existing project? > > + 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 :) > > Well I would prefer to have something from the 00 working now that from 2016 not working. > > Because now what I will do is continuing to work on Morphic because this is what I have. > You see I removed graphics from my future books. You probably do not care. > In the future I will concentrate on anything else than graphics and widgets like that I will have no frustration. > Hacking the compiler finally should be a lot nicer. > You see next week I go to visit alain and I will not discuss nor work on such topics like that no frustration. > > Finally I will not comment anymore on Bloc anymore. I should not have. > You do not seem to understand my point so I will shut up but years will pass before Bloc will be integrated in Pharo, because > integrated means maintained by us in case the guys behind bloc/brick get hired by anybody else on earth. > > > You seem to underestimate that part. > Ok you are super right and I'm super wrong. > > Stef -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Jan. 26, 2017

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

by Denis Kudriashov

2017-01-26 21:09 GMT+01:00 Bernhard Pieber <bernhard(a)pieber.com>: > > - 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. I also forgot to show in demo that it is possible to drag window tab to get normal separate window (just drag it to free space in World). I hope it will be enough because to my mind tabs are most suitable approach but when you really need separate window you will just drag tab out.

Jan. 26, 2017

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

by stepharong

> Hi, > > Then we will need Cairo + SDL2 (that does not work for us) I do not get why SDL20 would not work for us while it is used by gaming engines. Are we that special? We built interactive applications for Thales with complex event touch and now suddenly "it does not work for us" TM. I have the impression that each time I see Bloc we need something more special (now this is Gtk) To me it looks like it is a systematic "fuite en avant" with even more Mb consumption each time. Personally I do not care of blur and effects, or color max filters. Right now you do not even have a single example of something that is not a little demo. Why we cannot have a tk/tcl or red-language like working system? I mean working now and not relying on multiple MB of code extracted from an existing project? > + 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 :) Well I would prefer to have something from the 00 working now that from 2016 not working. Because now what I will do is continuing to work on Morphic because this is what I have. You see I removed graphics from my future books. You probably do not care. In the future I will concentrate on anything else than graphics and widgets like that I will have no frustration. Hacking the compiler finally should be a lot nicer. You see next week I go to visit alain and I will not discuss nor work on such topics like that no frustration. Finally I will not comment anymore on Bloc anymore. I should not have. You do not seem to understand my point so I will shut up but years will pass before Bloc will be integrated in Pharo, because integrated means maintained by us in case the guys behind bloc/brick get hired by anybody else on earth. You seem to underestimate that part. Ok you are super right and I'm super wrong. Stef

Jan. 26, 2017

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

by Tudor Girba

Hi Stef, As explained before Brick is where the main focus will be next. I think that once the editor will be working, we should see more visible movement in that department. Cheers, Doru > On Jan 26, 2017, at 8:39 PM, 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/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/ -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Jan. 26, 2017

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

by Tudor Girba

Hi, The mail from Alex is a bit cryptic. Alex, please send a more elaborate answer :). Cheers, Doru > On Jan 26, 2017, at 9:10 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > 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/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/ > -- www.tudorgirba.com www.feenk.com "Every thing has its own flow."

Jan. 26, 2017

Re: [Pharo-dev] Odd (and wrong) implementation of Float>>sign

by Nicolas Cellier

2017-01-26 21:22 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > 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. > OK, I think you are right > 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 > > maybe self isNan ifTrue [^-1 raisedTo: self signBit], or the standard tells it should be 0 too? > isSignMinus > ^((self at: 1) bitShift: -31) = 1 > > Which would restore symmetry, as well as conforming to all the relevant > specs. > > -Martin > > > Or just signBit ^(self at: 1) bitShift: -31) That means that we'd have to refactor most (all?) senders of sign...

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Eliot Miranda

Hi Torsten, On Wed, Jan 25, 2017 at 2:45 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > From my perspective: > > - I agree with Igor that "once" can be interpreted as "evaluate it only > once" as in > "Halt once". > > - I'm not sure but from the (now very distributed) discussion it is not > clear to me if > the #once mentioned by Eliot really has exactly the same behavior as > #memoized in Pharo. > Let's separate the implementation from the semantics. Memorizing a function implies cacheing its results for some set of arguments and answering the results, avoiding evaluating the function again. This is the effectively same semantics as [expr] once, which says that expire will be evaluated exactly once. So they're both forms of memorization. I recognized this but was too stupid/tired to realize they weren't the same, since once applies to nullify blocks and memorize applies to Nary blocks. That started this whole discussion, apologies. Now, descending to the implementations, I understand that Ben's memorize answers a block that wraps a dictionary which caches the arguments -> results mappings. #once is implemented to use become to convert the block (which in VW must be a clean block) into a cacheingBlockClosure which has an extra inst var to hold its values. We can make this work in Squeak and Pharo because we now have a prototype for clean blocks. So, quite different implementations, but very similar semantics That brings me to mention that in VW there's another, rather elegant, use for the once style block tricks, and that is to speed up step into in the debugger. Currently the implementation of step into is to simulate election (that's Smalltalk executing the InstructionStream byte code execution code, byte code by byte code) until control either returns or enters a block in the current method. That's slooooooow. The alternative is for the debugger to find all the blocks in the method and change their classes to a subclass of BlockClosure that raises an exception on value, and then use the step over code to get the VM to execute the code (via perform:) until either control returns or the exception is raised. The debugger then changes all the classes back and sets the focus to the current method. This is fast. Of course things get hairy when one considers debugging the debugger, but its all about the particular debugger only halting execution if it sees the exception is raised by the current set of blocks it has changed the classes of, and uses #pass to ignore any others created by other debuggers. > Does it also return a block that is caching the results and avoids a > second evalution > of the original block when having similar inputs? Also is there a > similar possibility > to give an own cache as in #memoizedUsing: for further tuning? > > - #memoizing is really not well explaining what it does but this seems to > be the official > term (also in other languages like Python, Java, JS, ...): > https://en.wikipedia.org/wiki/Memoization > > - maybe #withMemo(r)izingResults or #withCachingResults, #withReusedResults, > ... or something along that line > would be more intention revealing selectors > > > Side note: > ========= > - For license reason it would not make much sense to look into non-open > Smalltalks > - I have no idea about the VW version (and for obvious reasons dont want > to have a look) > - also dont know about other dialects if they have built in support for > memoization but it would be > good if Squeak, Pharo, Cuis, ... could align for such a case > - IMHO if #once and Pharos #memoization really have the same behavior then > compatibility for VW users > could be easily retained by adding #once to existing compatibility > layers (like "Grease") > > Bye > T. > > Gesendet: Mittwoch, 25. Januar 2017 um 22:30 Uhr > Von: "Igor Stasenko" <siguctua(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] memoized vs once > > #once can be interpreted as 'evaluate it once', > > but i don't like the #memoized .. it sounds painful to my ears. > It sounds like something stinking smeared across my face.. and i always > got stuck,confused and lost as the meaning of it always > escaping my mind, since it naturally defends itself from any unpleasant > thoughts. > > IMHO, maybe #once is not the best wording for what it does , but > #memoizing... yuck.. pardon me. > > > :) > > -- > Best regards, > Igor Stasenko. > > -- _,,,^..^,,,_ best, Eliot

Jan. 26, 2017