Concurrent Programming

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 <[hidden email]> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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@.squeakfoundation

>>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>>

>> seaside@.squeakfoundation

>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list

>> seaside@.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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Here's something you might consider. In this case, I render a page and then start gathering data to fill it. The "action" script gets fired when the page loads and then fires again every time "tinyThing" is clicked.


renderMiningOn: html
    | action myLoops buildFinished currData prevData |
   
    LOOPER := OrderedCollection new.
    myLoops := 0.
    miningPriceSelector ifNil: [miningPriceSelector := 2].
    self renderMiningPriceSelectorOn: html.
    prevData := currData := nil.
    buildFinished := false.
    html div id: 'incompleteTable001'; with: [].
    [
        self buildMiningData: [ :data :flag |
            prevData := currData.
            currData := data.
            buildFinished := flag.
        ].
    ] forkAt: Processor activePriority.

    action := html jQuery ajax
        script: [ :s |
            myLoops := myLoops + 1.
            myLoops > 100 ifTrue: [self halt].
            [currData == prevData & buildFinished not] whileTrue: [
                (Delay forMilliseconds: 300) wait
            ].
            currData ifNotNil: [
                s << (s jQuery: #incompleteTable001) html: [ :h |
                    self renderMiningFrom: currData on: h
                ].
            ].
            buildFinished ifTrue: [
                s << ((s jQuery: #moretocome) html: [ :h | h text: 'done']).
            ] ifFalse: [
                s << ((s jQuery: #moretocome) html: [ :h | h text: '...']).
                s << ((s jQuery: #tinyThing) trigger: 'click').
            ]
        ].
    html div id: 'moretocome'; with: [].
    html div
        id: 'tinyThing';
        onClick: action;
        with: [].
    html document addLoadScript: action

On 2/28/15 2:01 PM, sergio_101 wrote:

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 <[hidden email]> 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
>>> >

>> [hidden email]

>>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>> _______________________________________________
>>> seaside mailing list
>>>

>> [hidden email]

>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>>
>>
>> _______________________________________________
>> seaside mailing list

>> [hidden email]

>> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside