World: r3wp

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

I just want to share this cause I'm all excited... 


I've been working a lot with liquid recently and I think I've just 
tought of an algorithm which would allow "atomic" multithreading 
using liquid.


it would mean building a kernel which manages the nodes, but basically 
several threads would creep up a liquid processing network in an 
async manner and resolve branches out of order, based on a thread 
semaphore and a stack to realign dependencies...  


If this works... It means Elixir OS could possibly have a multithreaded 
kernel, resulting in ALL applications becoming multihreaded without 
any specific coding needed by the developpers.  :-)


adding a few networked services... you could leverge an entire cloud 
(render farm) without even having to code a single specific line 
of cloud and thread stuff, and this would be directly embeded at 
all levels of the OS down to the button properties... cause even 
the most basic gui properties are built up of tiny liquid nodes...

Sounds cool :)

its going to be a really brain numbing kernel to build, but I really 
see the whole flow in my head.  It doesn't feel impossible like random 
compression so far. ;-)

imagine it like if the kernel, knowing what functions are eventually 
going to be called, pre-emptively starts a concurrent stack and executes 
some stuff in advance, and then inserts the results just as the original 
thread encounters it.  now imagine this using 8 threads in parallel...

brainfuck anyone  ;-)

whenever two parts of a piece of code aren't interdependent, ex:

;-------------------------------
ctx: context [b: "111" prt: func [ data ][ print data return 77]]
result: call-some-func 66
ctx/prt result 
;-------------------------------


they can be forked independently... here both lines 1 and 2 can run 
concurrently, so that the third line, when encountered will already 
have its results, all it needs to do is make sure both ctx and result 
are done.  if it has to wait, then that line is put on the stack 
and the thread jumps to another part of the code in need of processing 
(possibly a part of  call-some-func() can be run concurrently.


when all upper dependencies are met, threads start popping back to 
parts of the code waiting down the stack. until all the code has 
been flushed and the last line of the initial function is all that 
is left to execute.

so instead of having a kernel using a stack its using a tree.  Am 
I right in saying that  this is a shift from the turing machine? 
 :-)

Take a look at petri-nets.

I have, but I think I should find a good book about them, cause I 
admit what I read about them never fully makes them obvious to understand.

sounds interesting ...do you intend to do some experiments ? I would 
also be interested to know if you will release some new examples 
of liquid.

some commercial stuff using liquid will be released publicly in a 
short while (within a few weeks maybe sooner).

what do you mean commercial...stuff you have doen for clients or 
apps you are selling?

client work which will be released as open source.

sounds cool...eager to check out...