World: r3wp

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.

.

a small liquid news tidbit.


liquid-paint is now being used as the core engine for two new commercial 
apps, one is going to be based on paint-lab, my up and comming vector 
paint app, which is already working pretty well.

can we try or see liquid-paint anywhere :) ?

it will be online this week-end... as part of the roll-out of my 
web site.

congrats !

cool

I'm eager to se what you got, Maxim.

I think he means he might be putting up screen shots ... is that 
right max?

I intend to put the source on-line.  

the version won't be the latest and sure is not intented to be pretty 
to look at, its just going to show the liquid-paint module in action 
and draw-based event processing.

this being said, this tool is critical in many things I need, like 
building graphs for docs, building my web graphics, server-side graphics 
module for mod_remark, so it will be updated often.

Will your web site be the actual Steel-toolkit web site or another 
you will start-up ?

I'm working on a completely new site, with more than just programming.

Did I miss the roll out?

posted on remark... release post-poned due to client work. ' :-/