World: r3wp

if you only want to use slim for testing out liquid, I suggest to 
follow the quickstart, it should get you started in a few minutes 
without fuss.

ah... just wanted to announce a little milestone of liquid useage 
 :-)   In the current instance of liquidator, event handling and 
window refresh have been successfully decoupled  :-)  this means 
I can refresh based on a timer, instead of based on input events... 
 so I can now properly scale interactively of the view based on its 
weight without even removing one event from the view  :-)


you'd say... but we can already do that... well not exactly... yes 
 you can prevent the call to 'show in your mouse handling... but 
can you prevent the whole processing occurence when you are interactivally 
editing an item?  hehe .


because of liquid's lazy computing, the actual processing is delayed 
until needed, and the show will only occur after this.   so I can 
call update 30 times a second, and it will still only call show when 
things have realy changed, inversly, I can change the data 100 times 
a second, and only the real number of calls to update will actually 
cause a data refresh of all dependent data which changed (like the 
draw block :-)

Do you mean something similar to this ?
	if data <> old-data [
		update-draw-block
		show window
	]

that is the concept, but liquid will know about any atom of data 
which needs to refresh, and will only recompute what HAS changed, 
so in the example you give, not all draw element will actually get 
refreshed, probably only one or two, and then, the draw block is 
relinked... the smarter you are within the processing (as usually) 
the faster will be the refresh rate.

what is your question Steeve?

here we are

hehe

so m question now

liquid is a type independent engine.

wan we connect block of values or only single values

*can

each node has a multitude of connectivity options.

and connect several other nodes (plugs) to any node, you can even 
label and separate your connections,

the actual data you transport through the connections (links) is 
arbitrary, and can change at each data change.

hmm ok

containers hold the input data, so you can put anything in them...

then the linked nodes, will link to those containers, or other nodes, 
and the processing of each node, will determine what is output from 
the node as source data for another node or as actual processed data.

for example, if i have a collection of nodes, each of them, relative 
to a string

all the strings form a rebol script

yes?

if i want  manage the insertion or the deletion of one line of my 
source

i have to create myself a nex node or delete it, exact ?

*new node

not nex

you create a new node, with the new line of text and link it AT the 
offset which you want , and then just ask the master node for its 
text, and it will give you the new output. (if that is what its processing 
does)

so:

node_a = "a string"      -->	\
				 | node_c.output = "a string of text"
node_b = "of text"        -->	/

is see

but if i insert a node between a and b, node c is not informed ?

if you then insert node_d after node_a:
node_a = "a string"      -->	\

node_d =" ... "             -->	 |  node_c.output = "a string ... 
of text"
node_b = "of text"        -->	/

its lazy... (unless you tell it not to be)

ok

so node_c KNOWS its not up to date but computes nothing unless you 
need its value.

good thing

and thus, even if you change any input node's values or link new 
stuff to node_c... none of that will actually call any processing, 
untill you ask for the content of  node_c

and now a more harder question

which is how I decoupled the refresh and the event handler of my 
graph editor.

if i insert a newline in the text of node_a

how can i split node_a in 2 nodes ?

is there a trick to  auto split a node foolowing a specific rule 
?

that management is up to you.  liquid is a core kernel.  its not 
a language-driven... on purpose.

ok

I could have waisted time on some kind of generic node manager, but 
even after a year of work, it would still be useless... cause nodes 
are about processing.

liquid is a hybrid of storage, association, synchronisation, dependencies, 
and some in between.  it does all of those things using the same 
core node, and allows you to build any kind of manager, or dependecy 
model over it.

since nodes actually are objects, its not some mysterious hidden 
thing you try to grasp by reverse thinking of cause effect.

another question ?

you actually have access to all core methods like link, cycle?,  
process, init, propagate, etc.

no problem  :-)

how can we manage bijective depedency ?

for example:

you mean two nodes which are symmetric but actually have different 
data?