World: r3wp

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.

How inter connected to rebol is LIQUID...meaning, does rebol make 
it easier to do this or could it (has it) been done in other languages?

Max, you have a communication problem. A lot of people are interested 
but "don't get it". If you want more people to give it a try you 
need to make the entry very easy. Questions and things I see:

1. Out of the box example: Download, start, works. No special tools, 
configs etc.

2. Simple wording and naming scheme, everything else just confuses 
everyone. (Your wording is not logical).

3. The whole data-flow stuff should be like a plug-in into existing 
R2 code. So I just want to take a simple VID based example, attach 
the dataflow stuff and give it a try.

If liquid forces me to use your adapted VID, include-system, libraries 
etc. your chances are low that I can make use of it.

This si very well said, I could not say it better :-)

1. liquid needs no config
2. the naming IS very logical.  

3. impossible, liquid is a kernel, you cannot plug liquid Over, you 
have to build tools with it.  and NO I don't force you to use anything 
cause I don't use it myself.

all of my graphics work, even glayout has always been using VID. 
 Using face/init face/action face/feel of standard vid gadgets... 
the blood example of liquid on rebo.org is such a VID example.


4. liquid has never forced you to use any adapted VID, using slim 
is one line of code, no "config and install required", liquid isn't 
even graphics related.

getting liquid has nothing to do with all of this... its the paradigm 
which is complex.

could you imagine writting an application without loops and ifs as 
the basic control structure?

there is one thing which liquid needs right now is more examples, 
more tutorials, but even more, its more liquified modules.

Sure, can't you? 

Or using no assignment?

that's how liquid works.

(no assignments)

See, you're getting it :-)

hehe.

One mind trick per evening... latr ;-)

liquid is so low-level, that it could replace the basic datatypes 
themselves, I we could code accessors like in python.  using python, 
I can build a liquid which replaces the core datatypes and makes 
it completely invisible.  this is not possible in R2 and I'm not 
sure accessors will be as open as they could in R3, time will tell... 
 at least brian seems to be on the same page as me wrt this.

amacleod: I missed your post... just noticed it... don't know why... 
the color makes it stand out... ' :-/