[Seaside] Re: Concurrent Programming

Sat Feb 28 19:01:41 UTC 2015

ahhh.. i need to get this info for processing into my image.. it will not
be passed into the browser until much later in the game. the reason i want
to do it this way is so that all this stuff is happening without the user
having to wait on it..

i will take a look at threadpool and futures..

thanks!

On Fri, Feb 27, 2015 at 10:12 PM Paul DeBruicker <pdebruic at gmail.com> wrote:

> Oh, and futures:
>
> http://onsmalltalk.com/smalltalk-concurrency-playing-with-futures
>
>
> You probably want Futures if you're gonna poll from the client.
>
>
>
>
>
>
> Paul DeBruicker wrote
> > Hmmmm.
> >
> > In your plain English example is what you want happening in the client
> > browser or in your smalltalk image, ideally?
> >
> >
> > If you want the friends data in your image then you should consider using
> > Ramon Leon's ThreadPool:
> > http://onsmalltalk.com/2010-07-28-a-simple-thread-pool-for-smalltalk .
> > I've kept it working here: http://smalltalkhub.com/#!/~
> pdebruic/ThreadPool
> > You could use it to get the friends data from Facebook into the image.
> > Then poll for results from the client to update any divs/views.  You can
> > queue the thread pool requests in your login callback before you even
> > begin rendering things.
> >
> >
> >
> > If you just want to load the friends into a div only in the client its
> > probably easier to write a JS function in an external file and call it
> > from Seaside using the info specific to the user. e.g.
> >
> > html div
> >     id:'friendList'
> >     script: ((html jQuery id: 'friendList') call: 'loadFriendList' with:
> > self userFacebookID).
> >
> >
> >
> > Look at the JSScript class for the definition of  #<< .  It just
> > concatenates the scripts.  The #script: method passes a stream into the
> > block, and the << writes whatever you've written onto that stream.  Check
> > the senders and implementors to get your bearings.
> >
> >
> > When you have time please send things like:
> >
> > "I think this code "____code example_____" should do  "____expected
> > behavior____" but instead it does "____jumbly voodoo_____" instead. What
> > don't I understand?
> >
> >
> > Hope this helps.
> >
> >
> > Paul
> >
> > sergio_101 wrote
> >> i think i am having alot of difficulty understanding out to phrase ajax
> >> and
> >> jquery calls in seaside.. everywhere else, i use jquery etc
> >> unobtrusively..
> >> so i don't leave the javacript world when i write javascript. i just
> >> can't
> >> seem to find anything that makes sense on how to do something as simple
> >> as
> >> this using pure seaside/smalltalk.
> >>
> >> i can't really even understand what the "<<" in:
> >> script: [ :s | s << (s jQuery: #logger) html: DateAndTime now
> >>      ]);
> >> does..
> >>
> >> in plain english, i would like to do this:
> >>
> >> - when the page loads, call the url as an ajax function
> >> - set the variable -> currentUser friendsList: (from the above)
> >>
> >> but i am not understanding how to even code this..
> >>
> >> thanks!
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Feb 27, 2015 at 3:27 PM Sebastian Sastre <
>
> >> sebastian@
>
> >>> wrote:
> >>
> >>> why the fork that way?
> >>>
> >>> I’d think more into make it a normal render page that has a little
> piece
> >>> of javascript that will do an ajax hit to a server callback to do
> >>> whatever
> >>> you want, no?
> >>>
> >>>
> >>>
> >>>
> >>> > On Feb 27, 2015, at 1:45 PM, sergio_101 &lt;
>
> >> sergio.rrd@
>
> >> &gt; wrote:
> >>> >
> >>> > i am currently writing a facebook application in seaside. one of the
> >>> most important pieces of data i need to retrieve is the user's friends
> >>> list. unfortunately, this could end up being a substantial amount of
> >>> data.
> >>> fortunately, the load time for this data is not horrible, just a few
> >>> seconds.
> >>> > i am making the assumption that while interacting with my app, the
> >>> user
> >>> will not be adding new friends mid stream, and that during each
> session,
> >>> the friends list will be static.
> >>> >
> >>> > what i would like to do is make this happen completely behind the
> >>> scenes, so that when the user logs in, the request for the friends list
> >>> is
> >>> fired off RIGHT AFTER the page is rendered.
> >>> > i read the section on concurrency in 'deep into pharo', and while
> >>> incomplete, it makes enough sense for me to try it.
> >>> > my question is.. i am going to do something like:
> >>> >
> >>> > [currentUser updateData] fork
> >>> >
> >>> > 1. if i want to do that RIGHT AFTER rendering, can i put that at the
> >>> end
> >>> of renderContentOn: html ?
> >>> > 2. when i want to work with the data, how would i know if it was done
> >>> updating? i was thinking of using a semaphore.. but how would i let the
> >>> next process know to keep waiting until the process was done? i would
> >>> want
> >>> to do something like: getFriendsList (but make sure process that
> >>> populates
> >>> it is done before running the request).
> >>> >
> >>> > thanks!
> >>> > _______________________________________________
> >>> > seaside mailing list
> >>> >
>
> >> seaside at .squeakfoundation
>
> >>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >>>
> >>> _______________________________________________
> >>> seaside mailing list
> >>>
>
> >> seaside at .squeakfoundation
>
> >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >>>
> >>
> >> _______________________________________________
> >> seaside mailing list
>
> >> seaside at .squeakfoundation
>
> >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/
> Concurrent-Programming-tp4808376p4808475.html
> Sent from the Seaside General mailing list archive at Nabble.com.
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150228/6f26662d/attachment.htm