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

Re: [Pharo-dev] Immutability support

by Denis Kudriashov

2017-01-26 8:11 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > The "CAN'T REACH" comment is there because execution never reach that part > of the code. If you write code there, it will never be executed. The > process code performs a return without pushing any value on stack. > Sorry Clement, maybe I am stupid but it is not clear for me. If I put halt after "CAN'T REACH" I got debugger which means that it "can reach". Maybe by "CAN'T REACH" you mean that any return value will not be used? But it is not true: if I return something it will be result of original assignment expression. But as you said it could crash VM. > > Signalling an error is safe if the error is never resumed. But you'll need > the returnNoValue for performance intensive modification tracking. > Do you have reproducible test case to crash VM when #attemptToAssign is badly implemented? It will help for framework implementation and would be nice description for method. In comment we can point to it. Because this magic with forking process is very confusing. Also I not get your "returnNoValue" sentence.

Jan. 26, 2017

Re: [Pharo-dev] CALL for GSoC project proposals

by Guillermo Polito

We just add project proposals there? On Wed, Jan 25, 2017 at 11:19 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > But I understand the process. > So I did a pass > > On Wed, Jan 25, 2017 at 11:05 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > >> Hi yuriy >> >> you could have done it a bit less brutal. >> >> Stef >> >> On Wed, Jan 25, 2017 at 10:52 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >> wrote: >> >>> Dear all, this year we plan to apply again as a mentoring organization >>> for Google Summer of Code. However, we are going to follow a different >>> strategy regarding project proposals. Instead of having a swarm of small >>> ideas we want to end up with around ten well-described projects. >>> >>> This is why I cleaned the topics file, and I ask all interested people >>> to propose the best one of your topics here: >>> https://github.com/pharo-project/pharo-project-proposals/blo >>> b/master/Topics.st >>> >>> There is a copy of the old file in case you want to remind what you >>> proposed last year: >>> https://github.com/pharo-project/pharo-project-proposals/blo >>> b/master/Topics-old.st >>> >>> As we are going for well-described projects with links to related >>> resources, pictures, prototype videos, etc. you can also add a standalone >>> file with a project description in some rich format to this dir: >>> https://github.com/pharo-project/pharo-project-proposals/tre >>> e/master/topics >>> >>> Again, we want around ten diverse and well-described projects with a >>> precise definition of the domain and the problem, possible solutions, and >>> expected benefits. So it also will be nice to have diverse projects, so if >>> you are collaborating with someone, please try to propose a joined project >>> that will have backup members (also crucial for the application) and do not >>> create multiple similar but less powerful projects. >>> >>> We heavily rely on the input of the community. >>> Letâs make Pharo great again ;P >>> Uko on behalf of the Pharo GSoC application team. >>> >> >> >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by Norbert Hartl

> Am 26.01.2017 um 08:11 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: > > The "CAN'T REACH" comment is there because execution never reach that part of the code. If you write code there, it will never be executed. The process code performs a return without pushing any value on stack. > Because you return from the sender, right? > Signalling an error is safe if the error is never resumed. But you'll need the returnNoValue for performance intensive modification tracking. > > Ok, while you are popping of the stack there is no way to return, right? I cannot see what it has to be that way but I can see that my approach cannot work this way. In my case the error is resumed because not resuming would defeat the purpose of having transparent modification tracking. I'll use announcements for it because it is a better fit for that anyway. Norbert > > On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > For the Process hack, it's because the call-back was designed to return no value. > > Now I am confused. > Why anybody needs to return value from this method? > And why there is "CAN'T REACH" comment at the end of method? > Do you mean that method should never return? > > It may look like it works when returning a value but you will have uncommon crashes. > > And is it safe to just signal error? >

Jan. 26, 2017

Re: [Pharo-dev] Immutability support

by ClÃ©ment Bera

The "CAN'T REACH" comment is there because execution never reach that part of the code. If you write code there, it will never be executed. The process code performs a return without pushing any value on stack. Signalling an error is safe if the error is never resumed. But you'll need the returnNoValue for performance intensive modification tracking. On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> For the Process hack, it's because the call-back was designed to return >>> no value. >> >> >> Now I am confused. >> Why anybody needs to return value from this method? >> And why there is "CAN'T REACH" comment at the end of method? >> Do you mean that method should never return? >> >> >>> It may look like it works when returning a value but you will have >>> uncommon crashes. >> >> > And is it safe to just signal error? >

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Eliot Miranda

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 <eliot.miranda(a)gmail.com> wrote: > > 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. > _,,,^..^,,,_ > best, Eliot

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by phil＠highoctane.be

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 BlockClosure>>#memoizedUsing: cache "Provide a memoization block using the given cache. So one can tune by passing a LRUCache for instance" ^[ :x | cache at: x ifAbsentPut: [ self value: x ] ] Basically a shorthand for your recommendation. But I would have put a cull: instead of value: because sometimes, like in my case, there is no parameter, the only useful thing is the cacheKey. And it would be nice to have the :v1 :v2 :vn version with the cache key being made out of the combination + cull:cull:cull: Really, this is just a shorthand. This is nicer IMHO than having cache at:ifAbsentPut: all over. | cache factorial result | cache := LRUCache new maximumWeight: 3. factorial := 0. "avoid not-initialised warning when saving method source" factorial := [ :n | n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n] ] memoizedUsing: cache. result := (1 to: 5) collect: factorial. Phil On Thu, Jan 26, 2017 at 1:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 26 January 2017 at 02:10, phil(a)highoctane.be <phil(a)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 exceptions to access session > storage.. > quite ineffective.. but it works. > for that purpose it is much better to use process-specific variables, that > live and die together with process that hosts them.. > but has significantly better access timings. and since seaside allocates a > separate process per session, that's perfect fit. > > in any case, the concern about getting rid of volatile data is covered.. > while with memoization, i don't see it. and that seems like a HUGE > argument against using it, > because it is more trouble in a long run than time saver when you just > start using it everywhere. > > > >> Phil >> >> >> > -- > Best regards, > Igor Stasenko. >

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

On 26 January 2017 at 02:10, phil(a)highoctane.be <phil(a)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 exceptions to access session storage.. quite ineffective.. but it works. for that purpose it is much better to use process-specific variables, that live and die together with process that hosts them.. but has significantly better access timings. and since seaside allocates a separate process per session, that's perfect fit. in any case, the concern about getting rid of volatile data is covered.. while with memoization, i don't see it. and that seems like a HUGE argument against using it, because it is more trouble in a long run than time saver when you just start using it everywhere. > Phil > > > -- Best regards, Igor Stasenko.

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

On 26 January 2017 at 02:10, phil(a)highoctane.be <phil(a)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 > nothing). > > and why that could be the problem in my example? you can always implement #at:ifAbsentPut: in the way you see fit.. cache disable. x := cache at: #something ifAbsentPut: [ blah ]. "always calculates, ignores the cache" cache enable. y := cache at: #something ifAbsentPut: [ blah ]. "prefers to calculate once, reuse result" you see what i mean? in any case you can easily avoid repeating same block twice.. that's for sure. > Memoization is useful for not having to write the caching thing all the > time. > > DynamicVariables are darker magic that this, right? > > Phil > > > On Thu, Jan 26, 2017 at 12:56 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> 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 system.. because i spent significant portion of my smalltalk >> life hunting for leaks and immortal references that you cannot get rid of, >> because some guy forgot to provide a nice and easy interface or api to >> get rid of volatile data.. like open files or socket connections, session >> etc etc.. >> and now.. let us welcome.. memoization. :) >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by phil＠highoctane.be

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 thing all the time. DynamicVariables are darker magic that this, right? Phil On Thu, Jan 26, 2017 at 12:56 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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 system.. because i spent significant portion of my smalltalk > life hunting for leaks and immortal references that you cannot get rid of, > because some guy forgot to provide a nice and easy interface or api to get > rid of volatile data.. like open files or socket connections, session etc > etc.. > and now.. let us welcome.. memoization. :) > > -- > Best regards, > Igor Stasenko. >

Jan. 26, 2017

Re: [Pharo-dev] memoized vs once

by Igor Stasenko

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 system.. because i spent significant portion of my smalltalk life hunting for leaks and immortal references that you cannot get rid of, because some guy forgot to provide a nice and easy interface or api to get rid of volatile data.. like open files or socket connections, session etc etc.. and now.. let us welcome.. memoization. :) -- Best regards, Igor Stasenko.

Jan. 25, 2017