World: r3wp

and it stay slow

It's a quandry. I already had to add a local function to get around 
the limits of FOREACH, because the alternatives were slower. Do you 
have a solution that handles both breaks and returns?

Keep in mind that returns are supposed to be passed through, but 
you can't detect them.

local function again.

the into option begins th have a huge cost....

Only in one case: Inserting into the middle of a series, which is 
usually slow. We could just special case that one situation, or accept 
that it is as slow as it is in the rest of REBOL.

Graham, how about making a jog processor context. The callback func 
is in there, along with a block to collect the data, so it knows 
what results it should get. Have each function call it back with 
its chunk of data. The callback collects the results, and checks 
to see when a "batch" is complete. Then you just need a timeout element 
(store the start time), and something to ping it. If you store the 
original calls, the processor can retry failed calls.

(about the unset! drawback) it was core 2.6.3.
i wondering if it's not a bug of 2.7.6

We should check if it was in the rest of the 2.7 series - 2.7.6 is 
recent, but 2.7.5 is 2 years old.

Gregg ... it's supposed to be real time .. push a button and see 
the graph.  I guess this is the same as Steeve suggests .. wait until 
the results come in, or timeout ...

I guess I should try and keep it simple vs trying to chain all the 
callbacks somehow.

If you can render the graph with partial data, do it each time data 
comes in, or set up a rendering callback that the data callback calls. 
Polling intervals (if needed) can be pretty short without burning 
the CPU. If it's on the net, there's no guarantee of real time. :-)

That's a thought ... it's on localhost ...

the rendering is in a browser ... so that's not going to work unfortunately 
as I can't make the browser refresh.

...without javascript or refresh tags...

The problem then shifts to determining how to make the browser only 
refresh when there is new data.

ajax

;-)

The data is being generated as json, and loaded  into an ajax widget 
when the page is first rendered.

you can just to a small ping to detect changes... it can even be 
a boolean request, thus really tiny and fast.

example?

I haven't done it myself, but where I used to work, the guy would 
put an invisible div with a refresh rate on it. and the contents 
was dynamic, whenever changes occured it triggered the calls for 
the other divs on the page.

something along those lines... I can't explain in better details. 
 that was like 4 years ago... but surely there are plenty of examples 
on the net not?  gmail does it.

maybe you can look into its code?  using firebug, you should be able 
to read the dynamic javascript it downloads.

Using javascript to solve a rebol programming problem :)

heheheh

well... isn't it a web problem?   the browser ...  yuk.

No, it's a Rebol problem.

If I used a different way of rendering the graph, I have the same 
problem back again.

So, I need to solve it at the REBOL side.

but you can render within a rebol client?

I think I'll have a go at my first idea which was to create a stack 
of functions

if you can do it within view... then you problem seems pretty simple 
to me... I did a 4 way async system with on-demand buttons, loading 
data from the net and bg transfers syncing all running clients with 
a central cerver.

one of the threads was using google as a meta-engine.

so... can the graph data be viewed within a rebol window?

no

yes ..

the data only ... not the graph

using gabriel's async (fixed for close port bug ) I built an async 
xfer context.

each context had an init, a buffer collection and an on-close event 
.

(on close function)

So, how did you know when all the data was collected?

and I used a simple face timer to poll through the async contexts 
to see if the xfer was finished.  then call the on-close event. and 
remove it from the list of "pending" xfers.

in the async port, you can react to the close port event directly.

so I would just do

done?: true

and the polling would immediately call the on-close

using view's port stack, instead of the network stack which was effectively 
closed by then.

view's port event stack

I set the face timer to 30 times a second, and really.... cpu useage 
was at 0% on my system.

presumably when one transfer finishes, it could check the others 
and then render if they were all finished.  Do I need to poll?