On 08/13/2010 09:16 AM, Kevin Qiu wrote:
>
> Do not put code at //1 or //2 Did my example show that? I don't
> think it did. //1 and //2 should be inside the SM. Did you code an
> implementation or just do a desk check?
>
>
> The whole point of syncing a series of async calls is to
>
>
> Do not put code at //1 or //2 Did my example show that? I don't think it
> did. //1 and //2 should be inside the SM. Did you code an implementation or
> just do a desk check?
>
The whole point of syncing a series of async calls is to make the flow of
execution deterministic. I put print stat
On Fri, Aug 13, 2010 at 7:23 AM, Kevin Qiu wrote:
> Jeff,
>
> is it safe to say the skeleton of your method looks like this?
>
> void execute() {
> // 1
> DeferredCommand.addCommand(new IncrementalCommand() { /* state machine
> logic as posted above */ }
> // 2
> }
>
> The problem is, Defer
cokol,
could you elaborate on the timer idea? namely, how do you block the current
executing method using a timer?
I'm sure I missed your point, but just for argument's sake, I cooked up this
method:
public void execute() {
Timer blocker = new Timer() {
public void run() {
while (curr
Jeff,
is it safe to say the skeleton of your method looks like this?
void execute() {
// 1
DeferredCommand.addCommand(new IncrementalCommand() { /* state machine
logic as posted above */ }
// 2
}
The problem is, DeferredCommand isn't blocking, so after
DeferredCommand.addCommand(...), what
write a class which can be used like this:
Executor.async(cmd1).async(cmd2).async(cmd3).sync(cmd4)
it gonna start cmd1..cmd3 and when all are finished it gonna start
cmd4
and go for observer pattern
everytime an async call finishes it checks if it was the last one, if
so it triggers cmd4,
being
On 08/12/2010 03:24 PM, Jeff Chimene wrote:
> On 08/12/2010 02:23 PM, Kevin Qiu wrote:
>> Thanks for taking the time. Although it's not clear what action you put
>> in the timer and what the timer is supposed to do
>
> It's a "processing occurring" timer. I think I mentioned it earlier, so
> I di
On 08/12/2010 02:23 PM, Kevin Qiu wrote:
> Thanks for taking the time. Although it's not clear what action you put
> in the timer and what the timer is supposed to do
It's a "processing occurring" timer. I think I mentioned it earlier, so
I didn't remove it from the example.
> (IncrementalComman
Thanks for taking the time. Although it's not clear what action you put in
the timer and what the timer is supposed to do (IncrementalCommand is
executed by DeferredCommand.CommandExecutor and it already has a timer with
timeslice set to 100ms). Also, I suppose you need to reset the "busy" flag
in
On 08/12/2010 12:50 PM, Kevin Qiu wrote:
> After some thought, I don't think putting it in IncrementalCommand and
> execute with DeferredCommand help much here. Jeff, If I understand you
> correctly, my execute method will look like this:
>
> class Executor {
> // declaration of list of commands
On 08/12/2010 12:50 PM, Kevin Qiu wrote:
> After some thought, I don't think putting it in IncrementalCommand and
> execute with DeferredCommand help much here. Jeff, If I understand you
> correctly, my execute method will look like this:
>
> class Executor {
> // declaration of list of commands
After some thought, I don't think putting it in IncrementalCommand and
execute with DeferredCommand help much here. Jeff, If I understand you
correctly, my execute method will look like this:
class Executor {
// declaration of list of commands
void execute() {
DeferredCommand.addCommand(ne
Thanks. That's helpful.
On Thu, Aug 12, 2010 at 12:05 PM, Jeff Chimene wrote:
> On 08/12/2010 08:38 AM, salk31 wrote:
> > Don't you have to count the async returning and then do yet another
> > callback?
> >
> > So hook into the callback of all your commands and then when the last
> > one is don
On 08/12/2010 08:38 AM, salk31 wrote:
> Don't you have to count the async returning and then do yet another
> callback?
>
> So hook into the callback of all your commands and then when the last
> one is done do the callback?
Extending salk31's logic:
Put your execute() inside a loop, inside an In
Don't you have to count the async returning and then do yet another
callback?
So hook into the callback of all your commands and then when the last
one is done do the callback?
On Aug 12, 3:30 pm, Kevin Qiu wrote:
> I don't know if the title makes sense but working with gwt for about 2
> years,
I don't know if the title makes sense but working with gwt for about 2
years, I often find myself in the position to mix both asynchronous and
synchronous (blocking) apis. It's easy to transform a synchronous call to
asynchronous, but the other way around is not immediately obvious to me,
especiall
16 matches
Mail list logo
