Re: [Pharo-dev] memoized vs once

> Hmm. Our language doesn't have method variables, either - class > variables, instance variables, and temp variables (among others). > > Maybe this should be called 'asTempConstant' ? (although a 'temporary > constant' sound really, really weird...) > > -cbc > Indeed , "temp variables" is what

Re: [Pharo-dev] memoized vs once

On Fri, Jan 27, 2017 at 7:12 AM, Dimitris Chloupis wrote: > > > heh.. you see my pain! right now i have to deal with C++ >> and seeing all these >> const Type & foo const.. >> and cannot parse it.. >> :) >> >> > I think that C++ tries to avoid this confusion by not using "method" for > the member

Re: [Pharo-dev] memoized vs once

heh.. you see my pain! right now i have to deal with C++ > and seeing all these > const Type & foo const.. > and cannot parse it.. > :) > > I think that C++ tries to avoid this confusion by not using "method" for the members of a method, so for example it does not define variables inside a method a

Re: [Pharo-dev] memoized vs once

2017-01-27 10:28 GMT+01:00 Denis Kudriashov : > > Ok, this is done 19611 > > . In 60361

Re: [Pharo-dev] memoized vs once

2017-01-26 23:28 GMT+01:00 Chris Cunningham : > On Thu, Jan 26, 2017 at 2:02 PM, stepharong wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann >> wrote: >> >> ... >> >> >>> Instead it is sent to an object that afterwards is a constant within a >>> method >>> (so it will not be eval

Re: [Pharo-dev] memoized vs once

> Am 27.01.2017 um 02:45 schrieb Igor Stasenko : > > > > On 27 January 2017 at 02:28, Ben Coman > wrote: > On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko > wrote: > > > > > > On 27 January 2017 at 01:30, Ben Coman >

Re: [Pharo-dev] memoized vs once

Le 27 janv. 2017 05:55, "Ben Coman" a écrit : On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda wrote: > > > Now, descending to the implementations, I understand that Ben's memorize... > btw, I feel a bit of an impostor having it called "my" memorize. It was Torsten's initiative based on gist by

Re: [Pharo-dev] memoized vs once

On Fri, Jan 27, 2017 at 4:32 AM, Eliot Miranda wrote: > > > Now, descending to the implementations, I understand that Ben's memorize... > btw, I feel a bit of an impostor having it called "my" memorize. It was Torsten's initiative based on gist by John Cromartie. https://pharo.fogbugz.com/f/case

Re: [Pharo-dev] memoized vs once

On 27 January 2017 at 03:45, Igor Stasenko wrote: > > > On 27 January 2017 at 02:28, Ben Coman wrote: > >> On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko >> wrote: >> > >> > >> > On 27 January 2017 at 01:30, Ben Coman wrote: >> >> >> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong >> wrote: >>

Re: [Pharo-dev] memoized vs once

On 27 January 2017 at 02:28, Ben Coman wrote: > On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko wrote: > > > > > > On 27 January 2017 at 01:30, Ben Coman wrote: > >> > >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong wrote: > >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann > >> > wrote

Re: [Pharo-dev] memoized vs once

On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko wrote: > > > On 27 January 2017 at 01:30, Ben Coman wrote: >> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong wrote: >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann >> > wrote: >> > >> >> stepharong wrote: >> >>> >> >>> can we rename this

Re: [Pharo-dev] memoized vs once

On 27 January 2017 at 01:30, Ben Coman wrote: > On Fri, Jan 27, 2017 at 6:02 AM, stepharong wrote: > > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann > wrote: > > > >> stepharong wrote: > >>> > >>> can we rename this selector? > >>> asMethodConst should be at least be renamed to asConstan

Re: [Pharo-dev] memoized vs once

On Fri, Jan 27, 2017 at 6:02 AM, stepharong wrote: > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann wrote: > >> stepharong wrote: >>> >>> can we rename this selector? >>> asMethodConst should be at least be renamed to asConstantMethod >> >> >> When you use "as {something}" then "something"

Re: [Pharo-dev] memoized vs once

On 27 January 2017 at 00:28, Chris Cunningham wrote: > On Thu, Jan 26, 2017 at 2:02 PM, stepharong wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann >> wrote: >> >> ... >> >> >>> Instead it is sent to an object that afterwards is a constant within a >>> method >>> (so it will not

Re: [Pharo-dev] memoized vs once

On Thu, Jan 26, 2017 at 2:02 PM, stepharong wrote: > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann > wrote: > > ... > > >> 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

Re: [Pharo-dev] memoized vs once

On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann wrote: 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

Re: [Pharo-dev] memoized vs once

ing #once to existing compatibility > layers (like "Grease") > > Bye > T. > > Gesendet: Mittwoch, 25. Januar 2017 um 22:30 Uhr > Von: "Igor Stasenko" > An: "Pharo Development List" > Betreff: Re: [Pharo-dev] memoized vs once > > #once c

Re: [Pharo-dev] memoized vs once

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

Re: [Pharo-dev] memoized vs once

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 : Hi Ben, via FaceBook via twitter I hear you've coined BlockClosure>>#memoized. Allow me to beg you to rename it to BlockClosure>>#on

Re: [Pharo-dev] memoized vs once

> On 26 Jan 2017, at 00:30, p...@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 (

Re: [Pharo-dev] memoized vs once

Oops, forgive me Ben. I'm wrong. once is only equivalent to memoized for nullary blocks. It is not the same as memoized:[value:] for N-ary blocks. Forgive the noise. _,,,^..^,,,_ (phone) > On Jan 25, 2017, at 10:56 AM, Eliot Miranda wrote: > > Hi Ben, > > via FaceBook via twitter I h

Re: [Pharo-dev] memoized vs once

There is the memoized with the internally declared Dictionary new as the cache and memoized using: cache There cache is known and the result is a block that does the caching thing. ([ :cacheKey| self getIssueCreateMetaWithExpandKeys: true ] memoizedUsing: self cache) value: #issueCreateMeta Blo

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 02:10, p...@highoctane.be wrote: > Ah ah :-D > > DynamicVariables are darker magic that this, right? > > you mean like those that seaside using? it lives as long as session lives, and tied to session you are working in.. in early versions of seaside they were using exception

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 02:10, p...@highoctane.be wrote: > Ah ah :-D > > In my example I want to be able to do the calls without caching or with > caching. Without for debugging because I amend the server side at times and > want always fresh data (yes, I could have a cache with TTL of about > noth

Re: [Pharo-dev] memoized vs once

Ah ah :-D In my example I want to be able to do the calls without caching or with caching. Without for debugging because I amend the server side at times and want always fresh data (yes, I could have a cache with TTL of about nothing). Memoization is useful for not having to write the caching thi

Re: [Pharo-dev] memoized vs once

Because caching are always comes with concerns, like when/where do we want to drop cached results and recalculate them, if needed.. With memoization it seems like there's simply no such concern at all.. meaning that cached data will live forever since created once.. which is never good for dynamic

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:40, p...@highoctane.be wrote: > Yeah, I get you 100%. > > I wanted to be able to cache or not and have this transparent. > > Memoization in its current form in Pharo is not like I would like to have > it. > > As for the repeating block, I was asking to how you would avoid

Re: [Pharo-dev] memoized vs once

Yeah, I get you 100%. I wanted to be able to cache or not and have this transparent. Memoization in its current form in Pharo is not like I would like to have it. As for the repeating block, I was asking to how you would avoid repeating in the given code structure. Phil On Thu, Jan 26, 2017 a

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:33, p...@highoctane.be wrote: > self memoize: #methodThatDoesSomethingLong:. > > would automatically store parameters values as cache keys. No matter how > many such parms. > > No need to have blocks or anything,operations are memoized. > We use blocks for lack of a bette

Re: [Pharo-dev] memoized vs once

self memoize: #methodThatDoesSomethingLong:. would automatically store parameters values as cache keys. No matter how many such parms. No need to have blocks or anything,operations are memoized. We use blocks for lack of a better way right now I guess. Phil On Thu, Jan 26, 2017 at 12:22 AM, Igo

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:23, p...@highoctane.be wrote: > Nothing new, that's the term. > > Memoization: After computing a solution to a subproblem, store it in a > table. Subsequent calls check the table to avoid redoing work. > > https://en.wikipedia.org/wiki/Memoization > > http://www.cas.mcmas

Re: [Pharo-dev] memoized vs once

But for caching you have a cache. The whole point of memoization support is to have it easy to do. Look at the bottom of this page: http://wiki.tcl.tk/10981 So if we could have some kind of the same using manipulation of thisContext and/or Slots, it would be nicer. e.g. SomeClass>>#initialize

Re: [Pharo-dev] memoized vs once

Nothing new, that's the term. Memoization: After computing a solution to a subproblem, store it in a table. Subsequent calls check the table to avoid redoing work. https://en.wikipedia.org/wiki/Memoization http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf http://wiki.tcl.tk/10779 I have been us

Re: [Pharo-dev] memoized vs once

result := [ do something long or short or whatever] cached. On 26 January 2017 at 01:20, Igor Stasenko wrote: > > > On 26 January 2017 at 01:14, p...@highoctane.be > wrote: > >> If one is doing any dynamic programming, the memoization term is pretty >> natural. >> >> for that purpose, i natural

Re: [Pharo-dev] memoized vs once

On 26 January 2017 at 01:14, p...@highoctane.be wrote: > If one is doing any dynamic programming, the memoization term is pretty > natural. > > for that purpose, i naturally using 'caching' wording. > https://youtu.be/OQ5jsbhAv_M?t=3m11s > > Phil > > On Wed, Jan 25, 2017 at 10:30 PM, Igor Stase

Re: [Pharo-dev] memoized vs once

Underscore.js names it also #memoize. http://underscorejs.org/#memoize Cheers On Jan 26, 2017 00:15, "p...@highoctane.be" wrote: If one is doing any dynamic programming, the memoization term is pretty natural. https://youtu.be/OQ5jsbhAv_M?t=3m11s Phil On Wed, Jan 25, 2017 at 10:30 PM, Igor S

Re: [Pharo-dev] memoized vs once

If one is doing any dynamic programming, the memoization term is pretty natural. https://youtu.be/OQ5jsbhAv_M?t=3m11s Phil On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko wrote: > #once can be interpreted as 'evaluate it once', > > but i don't like the #memoized .. it sounds painful to my ears

Re: [Pharo-dev] memoized vs once

All that is nice but I only found about it because I searched for "memoize"... Which is what it does. Phil On Wed, Jan 25, 2017 at 9:29 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > Hi Eliot, > you should have named the thread "once for all!" > +1 in any case > > 2017-01-25

Re: [Pharo-dev] memoized vs once

"Grease") Bye T. Gesendet: Mittwoch, 25. Januar 2017 um 22:30 Uhr Von: "Igor Stasenko" An: "Pharo Development List" Betreff: Re: [Pharo-dev] memoized vs once #once can be interpreted as 'evaluate it once',   but i don't like the #memoized .. it

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 a

Re: [Pharo-dev] memoized vs once

Hi Eliot. 2017-01-25 19:56 GMT+01:00 Eliot Miranda : > 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.

Re: [Pharo-dev] memoized vs once

Hi Eliot, you should have named the thread "once for all!" +1 in any case 2017-01-25 19:56 GMT+01:00 Eliot Miranda : > 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 implem

[Pharo-dev] memoized vs once

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 incompatib