World: r3wp

will also add a little integrated lib downloader.... to make it extra 
easy to use.

Sweet!  I'll be playing with it this weekend. =D

(in example app)

the code isn't intended to be compact... the goal is to help people 
understand.  I added a few comments which explain what/how/why some 
of the things.

How hard do you think it's going to be for you to port Liquid to 
R3?

I might also add a doc to explain some of the unobvious technical 
merits of the example.  people can say: "All that code just for that?" 
if they don't understand what is going on.

liquid R3... it could go really well, as it could be a bitch... if 
one little detail in a function breaks up the integrity of the whole.

the beauty of liquid is that broken code doesn't work, the side effect 
is that working code is unbreakable.

you can't "forget" to update something, everything is broken up into 
little systems.  the systems don't grow, you only have more of them, 
which is easier to manage and design, IMHO.

the one lib i can't wait to port is glob.  its like super gob, already 
in R2.

so in R3 its just going to be sooooo much faster.

You have such a strange way of wording things some times.  "broken 
code doesn't work, the side effect is that working code is unbreakable" 
 I'm not really sure what that means...

hehehe... means a system doesn't work at all until it does... and 
from that point on... its almost impossible to mess up.

Where is the example?

What I've seen working in Liquid really is phenominal but I've never 
really groked it so I was never able to figure out where to start 
when I tried to build things with it.

I'm hoping this example of yours will break the ice for me.

you just move on, and forget what has been done so far.  adding stuff 
to a system, doesn't mean patching old code.  it simply means tacking 
new systems to the old, and deciding how they relate.

tacking = adding

and apparently I missed the message saying you were uploading it

hehe.  I am just doing so... new version of slim just got uploaded 
(minor changes), liquid is almost ready.

the application will be there within the hour (need to build a friendly 
little rebol.org based slim lib D/L interface using VID)

if you can read (and understand) my last sentence... you are less 
tired than I am  ;-)

Interesting...  I'm a heavy prototyper.  I need one statement that 
does something to start with and I often have to see each additional 
statement functional before I can move on to the next.  If I spend 
enough time within a given environment I'll eventually be able to 
rebuild it from scratch but your code has always been deceptively 
simple so I often need an explanation of why you do what you do how 
you do it.

I really appreciate you making the example for me.  Hope you didn't 
mind the pestering, but it'll be good to finally see this dataflow 
in action

I added such comments throughout the code, it should be a pretty 
easy to grasp example, me thinks  :-)

I'm REALLY happy to do it.  its a great opportunity for me to actually 
get some limelight on liquid  :-)

I'll build a second version which has a skill editor  :-)

note, this application doesn't have the aspect-oriented stuff I was 
talking about... just pure liquid dataflow, all based on the !plug 
directly.

also note that liquid was NEVER optimised, so if you look at its 
code, you might find slow loops and such... I know!  for me, having 
it work without bugs and making it easy to maintain, is more important 
than raw speed... in all apps I've done using it, a single View face 
refresh slowed down the application more than alll liquid nodes combined, 
so the integrated lazy computing does enough optimisation on its 
own to make raw optimisation less of an issue.... but when I decide 
to go v2, I will make a "fast" version of the tool for production 
purposes... indentical in features, but with debugging removed and 
some loops optimised for speed.

the shared class, already speeds up the memory handling of the GC 
by a factor of 20 or 100 based on the size of your application (exponentially 
faster, as the app grows)

wow, just realised, I've been improving liquid for the last FIVE 
years !

Blood v0.1.1 released to rebol.org.


the first ever public demo of how to use liquid.  The application 
itself is very simple for now, but the code is pretty clean, has 
a lot of comments to explain a lot of what is going on.

so anyone got questions.... remarks... comments ?  just curious to 
know... I mean its been downloaded MANY times already  :-)

I've not had a chance to play with it yet, Max.

I suspect many of the downloads will be bots that like to index new 
content.....Not people passing by to check the scripts. New/changed 
scripts get prominent home page billing, so the bots come flocking 
to feast.

btw, the name blood comes from an old campaign manager I had built 
several years ago  :-)  (you can even see the links on the .org ML)

would it be possible to filter out bots based on their IP/traffic 
pattern?

To some extent, yes. We do record counts of "likely human views" 
vs "likely bot views" -- but the stat you see is the sum of the two. 
And the division is not perfect by any means.

I'll slightly reverse my previous statement......The "download this 
script" link is protected by a HTML attribute "rel=nofollow". That 
should prevent well-behaved bots from following the link. So the 
count of downloads is likely to to human rich.

could be nice to see them separate, maybe by adding a "probable bot 
%" next to the counts   :-)

I'm still looking through it.  I will modify some parts of it later 
today or tomorrow, and let you know if I have questions

I have a newer version which has the "ability modifiers" added as 
extra labels to the right of the abilites... it took me 5 minutes 
to do, and it only needs one new simple !plug derivative:

;- !ability-mod
!ability-mod: make !plug [
	valve: make valve [
		type: 'ability-mod
		;-----------------
		;-     process()
		;-----------------
		process: func [
			plug
			data
		][
			vin [{!ability-mod/process()}]
			plug/liquid: 0
			vprobe data
			if integer? data: pick data 1 [
				plug/liquid: to-integer (data - 11 / 2)
			]
			vout
		]
	]
]


and necessary linkage within the !character setup, and appropriate 
faces in the window layout.

currently preparing 2 liquid modules for distribution on rebol.org 
:
  * LIQUID-VID : adding liquid functionality to ANY vid face

  * GLUE : a (hopefully growing) set of reusable core !plug classes 
   (like !sum and !subtract, in blood example).

Well, I just got home from work.  I'm cooking some dinner which I 
will eat while watching last night's episode of Battlestar Galactica 
and then I will download Blood and play with it a bit.

cool

just thought I'd share this list I built while coaching someone in 
using liquid last night...

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

SANITY PRESERVING KNOWLEDGE WHEN USING LIQUID:
--------------------------------------------


#1:  liquid isn't a bully  - liquid shares its state, but asks for 
data (pulls, observes, etc) from its subordinates ("parents"), not 
the other way around (it doesn' push or force feed, like a highly 
inneficient signal messaging engine).


#2:  liquid is lazy by default - unless a plug or one of its observers 
 ("children") is stainless, nothing will process automatically (thus, 
faces usually are set to stainless, so that they refresh automatically).

#3:  liquid has several computing modes in a single base class.  
  * linking is for once sided dependencies
  * piping is for inter-dependencies or synchronisation
  * containment is for data storage
  * linked-containment is for processed data storage   


#4:  liquid mutates - plugs automatically change computing modes 
when you call some methods like linking, piping and filling.  depending 
on the order of these operations, a plug may "stick" to its previous 
computing mode.  e.g. a piped node remains piped, even you attempt 
to link it to something.


#5:  liquid is alive - remember that as you are setting up a liquid 
network, your plugs will start receiving messages as you are building 
up the tree, meaning that the process() (and other) functions might 
be triggered before every expected connections are done. always verify 
the integrity of the data before starting the process.  (i just got 
stumped by this one again, 5 minutes ago).


#6:  liquid is a collection of droplets - each plug should do one 
thing or manage one step of a process.  the more you break up the 
network, the better you will be at making it stable, reusable, flexible, 
and fast.


#7:  liquid is highly memory efficient - !plug uses shared classes. 
 so all the liquid operations are in a sub-object called a valve. 
 Thus, when you call internal functions, remember they are within 
the valve, and you must supply the plug as its first argument.  my-plug/valve/stats 
my-plug


#8:  liquid is volubile - its slim-based verbose & indented console 
printing engine (vprint) is YOUR BEST FRIEND.  use it profusely, 
to understand the chain of events and what the hell is going on.

adding a substantial feature to liquid.  the ability to "freeze" 
nodes.  the nice thing is that the freeze state can be set as a function... 
so a node could potentially disactivate itself on the fly, when it 
detects some impending error is about to occur.


it can also stay dead until its dependencies are sufficient... making 
it a highly efficient at preventing useless processing until all 
its dependencies are linked up.

you could even cause its to process only after a time lapse occured... 
automatically preventing useless processing within live animation 
nodes  :-)

What is vin / vout?

part of vprint system.

vin = vprint/indent
vout = vprint/outdent

they cause the console messaging to go in or out one tab for all 
further vprint/vprobe calls.