World: r3wp

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... ' :-/

rebol is a pretty closed language in the sense where there isn't 
much room to change rebol itself.  you can obviously replace functions, 
but not the real heart of the engine, the datatypes.  Other languages 
like python let you have access to the complete internals of the 
language.   This is often related to class usage, for which it is 
easier to provide hooks and callbacks. 


rebol is a language which doesn't promote objects as the core paradigm, 
its much closer to imperative programming than most "recent" languages. 
  R3 was/is? supposed to let us build our own datatypes, and has 
been reported as eventually providing for some level of accessors 
for objects.   This will make it easier to integrate tools like liquid 
seamlessly.

I often feel like there is a bridge to cross when using liquid.  
on one side, you have object and imperative code which needs a management 
layer over it, and on the other side, you have code that is more 
"aware", it is self-managed.  It knows what is going on, you tell 
it in advance what it should and then let it work on its own. 


 the hard part is to cross the bridge, both in understanding HOW to 
 use dataflow effectively (and that's not related to the name of the 
 functions ;-),   and then there is the actual coding where you'll 
 pretty much always have to bridge the gap between parts of an app 
 which are dataflow and those that aren't.

Max, I get all this. But how about using the normal graph notation: 
nodes and edges, direct, undirected, cycles etc.

Then extend it by Petri-Net notation using Tokens, Colors etc.

I'm pretty sure your concept maps to this.

one reason is that it doesn't map 1:1  plugs are both edges and nodes, 
for example.

.