World: r3wp

normally you have to know that whenever the list changes, you have 
a slew of functions to call, labels to update, what if the cursor 
changes, due to some insertion, deletion, what if the current selection 
is deleted... all examples which have to be handled globally... and 
the more the application grows, the hairier it becomes.

that will be my next personnal project..  I promise.

its easy to do... but right now I am working actually.

so it's not that easy then !

liquid is not about less code... its about unbreakable and long-term 
feature creep indiference.

its not easy, because we have to mix three paradigms into one application.

and dataflow is a management layer, so patching a flaky event engine 
like view's has to be done properly.

really hard, I did blood.r which has 16 interconnected fields, in 
an evening.

most of the time was spent with non liquid related things... like 
vid.

hum... I seem to be getting the reichart syndrome... there is a *NOT* 
missing before "really hard".

which is what I was saying, it's not easy.

easy is a vague term.

I'd rather say VIEW is the problem.  since liquid is pure.

and perfect   ;-)

but no, its not "hard" its just not a 5 line affair.

so at what point is there a payoff?

most of the time will be spent by me cursing after view trying to 
get the list to work.

16 nodes?

8 nodes?

payof is in:

 -robustness.  there are NO loose ends, no forgetting.  its impossible 
 by definition.

 -long-term dev speedup: adding features doesn't increase complexity, 
 since all features are developped completely independently.

 -speed: properly designed, lazyness can make an application quite 
 fast, even for very complex apps.  obviously, there are worst case 
 scenarios.. like anything.
 

add a dialect in the mix, and then the code size will shrink a lot, 
but since REBOL itself, isn't dataflow enabled, patching liquid within 
other REBOL components doesn't really benefit from a dialect.  cause 
creating, connecting and processing nodes is really simple.

to get two gui lists to share a dataset, will take as little as two 
nodes.

as I said, the liquid aspect of it is trivial.  its the view aspect... 
as always.  and view is still simpler than most gui engines I've 
used in the past.

just wanted to drop a little note saying that I have been using liquid 
for the last few days developping a brand new application (which 
I am not at liberty to disclose right now)  ...


DAMN... its just soooo sweet... really... adding features is "add 
and forget".   not "pry-in and pray" I have been adding feature after 
feature, everything is interconnected, graphical, and not only does 
it allow me to move forward without ever looking back, everything 
that is liquified in the software is down right unbreakble and bug 
free. 


software source  has trippled in size and I have spent only about 
4 hours in a whole week's worth of coding for resolving bugs.  More 
news to come in a little while.

It is really nice, but would be even nicer if we could play with 
Licquid as well :-) This is teasing!

liquid is on rebol.org for the several years has documentaion too... 
what do you mean?  you mean you'd like to play with the application? 
 well YOU now have access to it  :-)  you know where  :-)

well, it uploading right now, so will be there in afew minutes (3MB 
upload)

LOL I missed that Liquid was on rebol.org. I thought it was still 
work in progress :-)

I would be very interested to see what you can build with it and 
how its done. Ive looked at the docs briefly but I did not "get it".I 
should re-read them I guess.

I will be releasing the first liquified api shortly, called paint. 
 this is a rebrand of the infamous glob engine.  This engine allows 
people to use draw, just like if it where faces, where individual 
graphic elements (or groups of them) can receive face-like events.

so you can easily make paint packages like illustrator or custom 
interfaces which aren't bound to square shapes.

Maxim - would it be possible, somehow, to mix Liquid with VID 3.4? 
Or does it go so deep, that you have to use your won even processing, 
hence you start at View level, not using VID at all?

liquid is a kernel. its goal is to manage processing, by using messaging 
and state at the atomic level.  so it can be used by anything, anywhere.

I use liquid in VID in R2 almost exclusively.

but in a sense, API's like paint alleviate a large part of the need 
for VID.  cause the dataset is actually "aware", it doesn't need 
someone controling it... in fact its aware at such a granular level, 
than it can actually prevent the majority of processing from happening.

all you need is a controler which knows what the system is "supposed" 
to do, set it up... and leave it to run by itself.

in the app I am building right now, I'll give you the best example 
of how powerfull dataflow can be.  after developping a complex and 
interactive canvas, with animation, and stuff... a new spec comes 
along, that basically changes the coordinate system of the whole 
engine!!!

usually, you'd need to rebuild the whole system to take the changes 
into account, or backtrack all functions which interface the coordinates 
and make sure everyone is using the same values... etc.

with liquid, because the system is explicitely defined and dependencies 
are all resolved at the smallest resolvable value, It took me 4 lines 
of code to reburbish the whole application... all I needed was to 
add an an offset to the coordinate system and connect it to 2 other 
plugs... and every single part of the system now was receiving modified 
values.

we have tried to run liquid within R3 an it crashes rebol...  but 
I didn't have time to figure out why, its a pretty complex object. 
 but I will have to look at in sometime this summer... the simple 
10X speed gain of AGG is enough to make it worth, especially since 
gobs provide internally of what paint simulates in R2.

now if Carl is interested in working with me on making this a reality, 
I will definitely give some time to the effort.  even if we only 
use liquid for some part of VID it would make a lot of stufff SOOOO 
much simpler to write afterwards in application, and lazy programming 
really pays off in terms of economies of processing.  in my application, 
rendering 1 graphic or 100 cause no more processing in most circumstances! 
 only the AGG aspect of things slow down.

I'm in the middle of that very problem (changing an aspect of my 
interface and having to go through every function that is affected 
and change them). What you describe sounds awsome.

I also looked few times at this, it seems very interesting but I 
also didn't "get" it :) I will keep trying

liquid is like the distant philosophical cousing to parse... its 
strange, magical, makes wonders, but its hard to "get"   .   ;-)

what is the problem domain that you are trying to solve with Liquid? 
 Maybe that would help

applying dataflow to all aspects of computing, not just specialised 
vertical markets.

ultimately, to allow all liquified code to interconnect as one seamless 
system.  its already starting.  Once I have the network plug done 
(relatively easy but not yet a priority), things like the collaborative 
text editors are going to be trivial to code.


I am already working on a collaborative paint concept.  where we 
all draw and manipulate the same canvas without locking!

I even want to allow several people to play with individual CVs of 
a single shape concurrently... its actually harder not to allow it 
than to let it happen!

hm.. sounds mega interesting, I really need to dig into this a little 
more :)

me too   ;-)

ok I'm changing color for my nick... its going to "reflect" my constant 
ramblings about liquid.