World: r3wp

;-)

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?

the checkup loop was something like


you can do it that way too... but you might get into some strange 
stack issues, cause you end up handling  port messages from one port 
to another within the messaging stack... but I guess a simple test 
sould suffice to see if its stable or not.


in my case, the gui had to stay responsive, since the xfer-contexts 
had cancel methods, which interrupted any xfer in real-time, and 
the whole gui had to still handle events smoothly, like scrolling 
a huge list, while it was adding items to that list, as it parsed 
the return value from the google search engine  :-)

oops  hehe missing some lines there...

Does seem straight forward when you explain it like that :)

you verification could be something like:

unless all [ctx1/done? ctx2/done? ...] [ 
	;all done, do whatever
]

or using an integer with bit handling, it could be as simple as 

; a four bit setup
unless done-bits = 7 [
]

and to set individual "done" bits

xfer-context: [
  set-done: does[ 
     done-bits: done-bits OR power 2 index? find port-list self
  ]
]

:-)

usualy, when dealing with bits, it's better to use bitset!, all operations 
are faster (insertion, modification, search)

i noted that bitset! are mostly under rated by rebolers

I think it's about language compactness.

what do you mean ?

for non-compact languages like Rebol, users form their own compact 
subsets and tend to use them exclusively.

the bit example is just a 20 year old programming habit... hehehe 
 I do find the bit sets a bit awkwards...  but I use them profusely 
in parse... 
go figure... hehehe

So, better programmers will use more of the language than others. 
 Which is why it's a good idea to read other people's code :)

i use them not only in parse

i use them to build fast indexes for examples

So, C and Python are considered semi-compact languages, and C++ an 
anti-compact language.

I expect languages like REBOL and forth that expand their own dictionaries 
are not as compact as Python.