Handling async callbacks
Locked
12
12
 
|
I was just watching Rich Hickey's core async presentation (http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber.
-- Does amber/pharo have a queue system we can use? Cheers Andy You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
I don't know what can be the problem, you should specify more (I did not look at the presentation), but amber runs on JS which is single-thread; if the problem is async callbacks come in undefined order, well, yes, they do; there is no system in amber for that (solve it as hoc if you need a specific order).
Or was something else that problem? Herby Andy Burnett wrote: > I was just watching Rich Hickey's core async presentation > (http://www.infoq.com/presentations/clojure-core-async) and it made me > wonder how people are handling the async callback problems in amber. > > Does amber/pharo have a queue system we can use? > > Cheers > Andy > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email]. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Actually, what Rich was talking about was an approach to handling
"callback hell". He had implemented a queuing system which seemed to allow a simplified approach to the problem. I am curious whether people have developed any smalltalk'ish approaches to handling the callbacks in amber. Cheers Andy > On 23 Nov 2013, at 08:25, "Herby Vojčík" <[hidden email]> wrote: > > I don't know what can be the problem, you should specify more (I did not look at the presentation), but amber runs on JS which is single-thread; if the problem is async callbacks come in undefined order, well, yes, they do; there is no system in amber for that (solve it as hoc if you need a specific order). > > Or was something else that problem? > > Herby > > Andy Burnett wrote: >> I was just watching Rich Hickey's core async presentation (http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber. >> >> Does amber/pharo have a queue system we can use? >> >> Cheers >> Andy >> >> -- >> You received this message because you are subscribed to the Google Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Andy Burnett wrote: > Actually, what Rich was talking about was an approach to handling > "callback hell". He had implemented a queuing system which seemed to > allow a simplified approach to the problem. I see. I don't know. There is Promises/A and similar more-or-less-standards in JS with implementations (q, jquery's Deferred), promises are going to be (or not? I kind-of-stopped watching es-discuss) part of upcoming ECMAScript 6. All of this can be use by Amber. Of course, if Pharo or other Smalltalk dialect has its own notion of promises, they could be reused (but I don't think so - traditional Smalltalk with green threads is different platform that strictly single-thread-callbackish JS, so there may be less need for it), but I admin I don't know. Herby > I am curious whether people have developed any smalltalk'ish > approaches to handling the callbacks in amber. > > Cheers > Andy > >> On 23 Nov 2013, at 08:25, "Herby Vojčík"<[hidden email]> wrote: >> >> I don't know what can be the problem, you should specify more (I did not look at the presentation), but amber runs on JS which is single-thread; if the problem is async callbacks come in undefined order, well, yes, they do; there is no system in amber for that (solve it as hoc if you need a specific order). >> >> Or was something else that problem? >> >> Herby >> >> Andy Burnett wrote: >>> I was just watching Rich Hickey's core async presentation (http://www.infoq.com/presentations/clojure-core-async) and it made me wonder how people are handling the async callback problems in amber. >>> >>> Does amber/pharo have a queue system we can use? >>> >>> Cheers >>> Andy >>> >>> -- >>> You received this message because you are subscribed to the Google Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >>> For more options, visit https://groups.google.com/groups/opt_out. >> -- >> You receiv >> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. >> For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Handling async callbacks
|
In reply to this post by Andy Burnett
Yes it's callback hell.
But with Amber I feel it's easier to "keep going." I use a lot the suffix 'Do: aBlock' like whateverDo: aBlockReaction You ask the facebook API to login a user? Implement a signInDo: aBlock it interrupts your intuitive flow of behaviour but that's what networks ultimately need PD: so when you need to "concatenate" behaviour that's async you can do something like self stepOneDo:[:answer| answer ifTrue:[self stepTwoDo:[ thigns... ]] ifFalse:[ 'oh noes!'] is not too bad On Nov 23, 2013, at 11:34 AM, Andy Burnett <[hidden email]> wrote: Actually, what Rich was talking about was an approach to handling You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
OK, Thank you to both of you. I suppose it isn't too much of a problem if the call back depth, or complexity, is low.
However, I would like to use amber to write more node server stuff, so I will look into the idea of queues. Maybe there is something we can implement. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Andy Burnett wrote: > OK, > Thank you to both of you. > > I suppose it isn't too much of a problem if the call back depth, or > complexity, is low. > > However, I would like to use amber to write more node server stuff, so I > will look into the idea of queues. Maybe there is something we can > implement. Just to be sure I was understood: you can take for example q promise library, or some simple node-specific solution like creationix's steps, and use it as is. Why reinvent the wheel (unless of course you need something else than they provide)? Herby -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Handling async callbacks
|
|
In reply to this post by Andy Burnett
I'm curious why would you need a queue? (my guess is that you should manage to not need them)
parallelization it's all about the opposite of queues no? On Nov 23, 2013, at 12:21 PM, Andy Burnett <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
sebastian wrote:
> I'm curious why would you need a queue? (my guess is that you should > manage to /not/ need them) > > parallelization it's all about the opposite of queues In node, where every net and file access is async by default (though some sync ones exist, but they block the thread), you need some way to maintain the order for simple sequences of steps. So I guess it is about pervasive async nature of sequential tasks, not about parallel one. > no? > > > > On Nov 23, 2013, at 12:21 PM, Andy Burnett > <[hidden email] > <mailto:[hidden email]>> wrote: > >> OK, >> Thank you to both of you. >> >> I suppose it isn't too much of a problem if the call back depth, or >> complexity, is low. >> >> However, I would like to use amber to write more node server stuff, >> so I will look into the idea of queues. Maybe there is something we >> can implement. >> >> On 23 Nov 2013, at 08:46, sebastian <[hidden email] >> <mailto:seb >> >>> Yes it's callback hell. >>> >>> But with Amber I feel it's easier to "keep going." >>> <http://www.brainyquote.com/quotes/quotes/w/winstonchu103788.html> >>> >>> I use a lot the suffix 'Do: aBlock' >>> >>> like whateverDo: aBlockReaction >>> >>> You ask the facebook API to login a user? >>> >>> Implement a >>> >>> signInDo: aBlock >>> >>> it interrupts your intuitive flow of behaviour but that's what >>> networks ultimately need >>> >>> sebastian <https://about.me/sebastianconcept> >>> >>> o/ >>> >>> PD: so when you need to "concatenate" behaviour that's async you can >>> do something like >>> >>> self stepOneDo:[:answer| >>> answer >>> ifTrue:[self stepTwoDo:[ thigns... ]] ifFalse:[ 'oh noes!'] >>> >>> is not too bad >>> >>> >>> >>> >>> On Nov 23, 2013, at 11:34 AM, Andy Burnett >>> <[hidden email] >>> <mailto:[hidden email]>> wrote: >>> >>>> Actually, what Rich was talking about was an approach t >>>> "callback hell". He had implemented a queuing system which seemed to >>>> allow a simplified approach to the problem. >>>> >>>> I am curious whether people have developed any smalltalk'ish >>>> approaches to handling the callbacks in amber. >>>> >>>> Cheers >>>> Andy >>>> >>>>> On 23 Nov 2013, at 08:25, "Herby Vojčík" <[hidden email] >>>>> <mailto:[hidden email]>> wrote: >>>>> >>>>> I don't know what can be the problem, you should specify more (I >>>>> did not look at the presentation), but amber runs on JS which is >>>>> single-thread; if the problem is async callbacks come in undefined >>>>> order, well, yes, they do; there is no system in amber for that >>>>> (solve it as hoc if you need a specific order). >>>>> >>>>> Or was something else that problem? >>>>> >>>>> Herby >>>>> >>>>> Andy Burnett wrote: >>>>>> I was just watching Rich Hickey's core async presentation >>>>>> (http://www.infoq.com/presentations/clojure-core-async) and it >>>>>> ma >>>>>> problems in amber. >>>>>> >>>>>> Does amber/pharo have a queue system we can use? >>>>>> >>>>>> Cheers >>>>>> Andy >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the >>>>>> Google Groups "amber-lang" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [hidden email] >>>>>> <mailto:[hidden email]>. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "amber-lang" group. >>>>> To unsubscribe from this group and stop receiving emails from it, >>>>> send an email to [hidden email] >>>>> <mailto:[hidden email]>. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> -- >>>> You receiv >>>> Groups "amber-lang" group. >>>> To unsubscribe from this group and stop receiving emails from it, >>>> send an email to [hidden email] >>>> <mailto:[hidden email]>. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "amber-lang" group. >>> To unsubscribe from this group and stop receiving emails from it, >>> send an email to [hidden email] >>> <mailto:[hidden email]>. >>> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "amber-lang" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an email to [hidden email] >> <mailto:amber-lang >> For more options, visit https://groups.google.com/groups/opt_out. > > -- > You received this message because you are subscribed to the Google > Groups "amber-lang" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [hidden email]. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
You should checkout "concurrent smalltalk" to get some ideas of what concurrency in smalltalk could look like http://www.dtic.mil/get-tr-doc/pdf?AD=ADA259417
Another attempt is found in smalltalk90 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.35.1907
And finally http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.50.3474&rep=rep1&type=PDF is directly relating to csp and pi calculus for smalltalk. On Saturday, November 23, 2013, Herby Vojčík wrote: sebastian wrote: You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Also regarding regarding concurrent smalltalk: http://books.google.com/books?id=ugn-mbhZQjAC&pg=PA4&lpg=PA4&dq=%22The+Design+and+Implementation+of+ConcurrentSmalltalk%22&source=bl&ots=OSg2d0_KoY&sig=rxHsq-5XKSw4Fk-DrzFf10y9WlE&hl=en&sa=X&ei=ae6QUo_NNo6NigLizIHQCg&ved=0CD0Q6AEwAw#v=onepage&q=%22The%20Design%20and%20Implementation%20of%20ConcurrentSmalltalk%22&f=false seems to contain most of the content from the book and directly addresses CSP etc. On Sat, Nov 23, 2013 at 9:11 AM, Shaun Gilchrist <[hidden email]> wrote: You should checkout "concurrent smalltalk" to get some ideas of what concurrency in smalltalk could look like http://www.dtic.mil/get-tr-doc/pdf?AD=ADA259417 You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
In reply to this post by Herby Vojčík
Cheers Andy You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
In reply to this post by Herby Vojčík
I think Herby summarised it well. And, I hasten to add, I am no expert on this topic. I simply mentioned queues because this seemed to be how they had implemented it in Clojure. The logic was that by having multireader and multiwriter queues one could centralise one's logic, rather than distributing it over a number of different callbacks. Events that returned through the queue would then trigger the resumption of functions.
-- Cheers Andy On Sat, Nov 23, 2013 at 10:50 AM, Herby Vojčík <[hidden email]> wrote: sebastian wrote: You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
In reply to this post by shaun gilchrist
Brilliant!
-- Thanks very much On Sat, Nov 23, 2013 at 12:11 PM, Shaun Gilchrist <[hidden email]> wrote: You should checkout "concurrent smalltalk" to get some ideas of what concurrency in smalltalk could look like http://www.dtic.mil/get-tr-doc/pdf?AD=ADA259417 You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Handling async callbacks
|
I urge you guys to watch Rich's core.async talk to the end. He makes the point that promises/futures are really only a partial solution when dealing with asynchronous events. What they've done in core.async is to go beyond that and provide something like GO's channels. These channels are queues, but the API you'd use abstracts the access details. This is because core.async is intended to be used from both Clojure and ClojureScript where the first supports multiple threads while the second (which compiles to JavaScript as Amber) doesn't. It's a beautiful solution, IMO, and maybe the way they've done it could inspire a similar solution for async and concurrency (at least the appearance of it under JS) handling in Amber. Really the most valuable points in Hickey's talk are made towards the end, so the whole thing should be seen. -- Adrian You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
In reply to this post by Andy Burnett
Hi Andy and others,
-- While core.async is certainly nice (check out some of swannodette's cool ClojureScript demos too), I do find promises (and family) to be useful programming conveniences when concurrency is not the primary technical muscle being brought to solving the problem at hand. Towards this, I've been working on a Promise class for Amber and would like some feedback from the amber community on it. The package's source is in the "promise" branch of my amber fork. https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st It is work-in-progress, but is documented enough to be useful I think (click the "Doc" checkbox in Helios). Promise is based on the Promises/A+ specification, but is more smalltalk-ish and has some smalltalk-specific goodies - ex: you can send a message to the value being promised as though it were available right away .. and the result will be a promise that will yield the return value of the message when it eventually gets sent. In other words, you can use a promise for a value pretty much as though the value were available right away. Best, -Kumar On Saturday, November 23, 2013 6:51:14 PM UTC+5:30, Andy Burnett wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Srikumar Subramanian wrote: > The package's source is in the "promise" branch of my amber fork. > https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st Technical: You are supposed to map 'namespace' and 'namespace/_source' to some real directory. We may use that fact that xxx/_source is unmapped as a detection tool if sources are available, so it would be better not to `require.toUrl('my_ns')+'/source' == require.toUrl('my_ns/_source')`. -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Thanks Herby. Will do that. That "promise" branch is only temporary though and I won't submit a pull request on that :)
-- Btw after the release of 0.12.x, is the recommendation for sharing libraries written for smalltalk/amber simply to put the compiled .js files somewhere it can be AMD-loaded via URL? On Thursday, December 12, 2013 7:20:33 PM UTC+5:30, Herby wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
|
|
Hi! IMHO the best way to provide a library is to provide a bower component. Both the smalltalk and javascript files should be included so that people can read its source code in the system browser. Amber itself will probably be modularized in the future, having the runtime separated from the IDE, etc. Cheers, Nico Srikumar Subramanian writes: > Thanks Herby. Will do that. That "promise" branch is only temporary though > and I won't submit a pull request on that :) > > Btw after the release of 0.12.x, is the recommendation for sharing > libraries written for smalltalk/amber simply to put the compiled .js files > somewhere it can be AMD-loaded via URL? > > On Thursday, December 12, 2013 7:20:33 PM UTC+5:30, Herby wrote: >> >> >> >> Srikumar Subramanian wrote: >> > The package's source is in the "promise" branch of my amber fork. >> > >> https://github.com/srikumarks/amber/blob/promise/org_sriku/_source/Promise.st >> >> Technical: You are supposed to map 'namespace' and 'namespace/_source' to >> some real directory. We may use that fact that xxx/_source is unmapped as a >> detection tool if sources are available, so it would be better not to >> `require.toUrl('my_ns')+'/source' == require.toUrl('my_ns/_source')`. >> -- Nicolas Petton http://nicolas-petton.fr -- You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
Re: Handling async callbacks
|
|
In reply to this post by Kumar
Hi Kumar, it seems that you are using the Promises API which is going to be implemented in ES6, right? Recently I read the following article about the upcoming Promises support, but it wasn't clear to me if you are actually using this API:
What I was also wondering about is why you need methods like 'commit' or 'fullfill' (which is not in the API description I read) or why you need to handle the state of the promise yourself (which should already be handled by the ES Promise object if I understood this correctly).
Wouldn't it be easier to just create a lightweight wrapper around the original Promise object? Best, Manfred
On Thu, Dec 12, 2013 at 8:20 AM, Srikumar Subramanian <[hidden email]> wrote:
You received this message because you are subscribed to the Google Groups "amber-lang" group. To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email]. For more options, visit https://groups.google.com/groups/opt_out. |
«
Return to Amber Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |