World: r3wp

this is embeded within the slim manager and is added to any slim 
library automatically

That makes sense.   I will be  working on extending your blood to 
be as featured as the other char gen I made over the course of the 
week, so I"m sure I will run into all sorts of fun questions during 
the process

the vprint engine I mean... the actual vin/vout code is written manually

just passed all night helping ammon add new functionality to the 
+/- buttons... hehe the learning curve is steep, but gradually flatens.

hense the 8 rules above.... they really explain about 90% of all 
stumps even I fall over occasionally.

So I'm trying to create a plug, !color, that simply forces it's content 
to be a tuple, here's what I thought would work:

!color: make !plug [
	stainless?: true
	valve: make valve [
		type: 'color
		;-----------------
		;-     process()
		;-----------------
		process: func [
			plug
			data
			/value ; faster than:  /local value  
		][
			vin [{!color/process()}]
			plug/liquid: 0.0.0
			unless empty? data [
				if tuple? data/1 plug/liquid: data/1
			]
			vout
		]
	]
]

c: liquify/piped !color
fill c  255.255.255
fill c [0 0 0]



at this point c's content should be 255.255.255 not [0 0 0] which 
it is.

one note...  you might want to wait for me to release liquid-vid 
and glue... they will both simplify coding of things a lot.  and 
liquid-vid will even have a few dynamically adjusting faces like 
row and column.


funny thing is that its taking me far less energy (and code) to implement 
more dynamic and smart faces than glayout so far.  its also taking 
a lot less code to do a lot of the same things in glayout.

rule # 7


once you piped the color, processing is by passed.  this is a philosophical 
design decision.

Well, initially I tried it without /piped but FILL threw an error.

pipes and containers are like storage.  their value is to be used 
as-is.  if you wanted to clean ANOTHER plug to a color, your code 
is correct

interesting...

p: liquify/piped !plug
c: liquify !color
link c p
fill p  255.255.255
fill p [0 0 0]

does what I want it to.

Sweet.

btw, I am now building up a series of sample files for use as a tutorial 
as you guys ask questions and post examples.  so from now on, most 
of the question will be compiled into a great collection, used for 
an eventual tutorial!


so keep the questions comming.  independent and explicit code examples 
like the above are excellent.

exactly.

ammon in the above, the /piped is superfluous  ( and in fact a waste, 
since the p plug only needs to contain data)

Result of the same code minus the /piped ...

>> fill p green
liquid/!plug(1)/fill [
** Script Error: pipe expected plug argument of type: object
** Where: fill
** Near: either any [
    plug/valve/pipe
    plug/pipe?
] [
    plug: plug/valve/pipe/always plug
] [
    plug/pipe?: 'simple
]

sorry that is a BUG in liquid! hahahaha discovered it last night... 
well at 5am before I went to power nap.

its fixed and I wonder when that bug got inserted in the first place. 
 there is another tiny bug which I squashed, which was added with 
a brand-new (and not very teste) feature .

what version of liquid do you have on your system?

Whatever Blood.r pulled down...  One second...

0.7.0

darn, I just checked... I was sure I had updated the version late 
last night to include the fix... but seems not

my bad. give me a second... I will upload v0.7.1

ok, verified that the freeze extension works properly with blood, 
so its a valid release for now.

will also make sure that my reply to your original question (built 
a little example in my tutorial folder) also is functional

almost done...

version 0.7.1 released on rebol.org.

so, working now?

!color: make !plug [
	valve: make valve [
		type: 'color
		;-----------------
		;-     process()
		;-----------------
		purify: func [
			plug
		][
			vin [{!color/purify()}]
			if integer? plug/liquid [
				; convert integer to b/w gradient
				plug/liquid: to-tuple head insert/dup copy [] plug/liquid 3
			]
			unless tuple? plug/liquid [
				plug/liquid: 0.0.0
			]
			vout

   ; this is ESSENTIAL determines if plug is dirty or not... basically

   ; if you return false, the node stays dirty... and is re-evaluated 
   everytime.
			; if you forget to return a value, liquid causes an error. 
			true
		]
	]
]

print "----"
c: liquify !color
fill c  255.255.255
probe content c
fill c  none
probe content c
fill c  11
probe content c

p: liquify !plug
link/reset c p 

; /reset is used to reset the state of the plug as 
; virgin plug before linking. (all links removed, 
; pipes and containers are forgotten/ignored)
; if /reset isn't used, the plug c WILL be linked
; but its links are ignored, since the plug is 
fill p 55



output:

255.255.255
0.0.0
11.11.11
55.55.55

oops missing last probe in the above:

probe content c

Yes, my code is working but it's capable of a bit more than that...

do you understand the example I give?

btw purification always occurs after processing... which is why it 
uses plug/liquid directly... at that point any processing would have 
occured... if any

Yes, I understand it.   I'll be modifying my code to use both process() 
and purify() as I'm currently capable of linking multiple plugs to 
!color to set r.g.b separately and I need process for that but purify 
to ensure I have a tuple.

that's exactly the point of separating them :-)

btw adding node freezing, a very fundamental change to the engine, 
took  a huge 4 lines and about 40 bytes to implement!

announcing stream !  I am in the midst of  adding some more functionality 
to liquid which allows it to act as a signal processor (push method 
data-flow) the nice thing is that its incorporated  in the same plug, 
again, and using message stream will retain 100% compatibility with 
all the current plug featureset.

this will allow us to use window events directly within a lazy computing 
environment, for example, or provide dependency notification of child 
to parent changes.  this will allows a node to send a manual signal 
"downstream" and possibly take processing/setup decisions based on 
those messages.  downstream nodes should be able to return data in 
order to feedback the effects of the signal to its author, which 
might then, also activate some code.

so for liquid, this means a processing decision can be based on downstream 
nodes capability to handle it,  its like look-ahead processing

Max, you should take a look at petri-nets. I'm sure it will give 
you a lot of inspiration.

Woohoo, finally starting to make some progress with my comprehension 
of !Liquid!

And I'm building up a lot of code and information for creating tutorials 
 :-)

I'm finding myself writing standard test code for each plug type 
as I go along and I was just thinking it would be nice if I could 
add the code as a block on the plug such that I could test any plug 
type by calling 

liquify/test !plug


Or something like that...  Could be a nice documentation/usage example 
feature.

that is a Tremedous idea.  I even know how It could be done... be 
carefull I might put you in charge of developping it   :-)

Sounds good to me!

As you know, I just totaly reviewed how liquid-vid will handle its 
layout (now a live prodecural network in its own), so I am hard at 
work building that, but I will definitely put some time on integrated 
unit testing, when I rebuild the visual graph editor.  its such a 
great idea, as we have discussed, the I/O aspect of plugs cannot 
be ignored in dataflow, so this would be a great way to profile, 
document and verify expected node behaviour.

BTW...  I seem to be seeing a node processing it's liquid when it 
shouldn't be.  Once a node is liquified, filled and purified it shouldn't 
call process() or purify() again until it is filled again, should 
it?

this and the !plug/document.

I really can't wait to play with liquid-vid.

btw there is already a plug/valve/stats feature embedded within, 
which gives you the node's current state and setup.