World: r3wp

know = now

cool  :-)

the most basic thing to understand about liquid is that the central 
part of any application is not the interface... its the DATA.

notice that the integer range is not applied to the field... its 
applied to the ABILITY.

no matter how you try to set the ability, IT will always be clamped... 
there is no way to break it.

so the field just inherits that behaviour FROM the character WITHOUT 
ANY SINGLE LINE OF CODE it became an integer field.

a subtle but extremely powerfull and explicit demonstration of dataflow 
robustness.

glue now has a plug that returns gfx text size given any value and 
a font  :-)

WTF?!?  How did you do it?  This is EXACTLY what I've been working 
on!

-------------------------------------------------
NOTE:  

FROM NOW ON, 

every usable !plug definition that I post will be in black, to make 
it easy to differentiate from test code, and copy in your own libs.

-------------------------------------------------

	;-     glue-proc-face:
	glue-proc-face: make face [size: 100x100] 

	;-----------------
	;- !gfx-text-area
	;-----------------

 ; this class returns the area which a value, when represented as 
 a string, occupies.
	;
	; returns: a pair representing width and height
	;
	; usage:

 ;  linked only, unlabeled.  (filling this node will permanently freeze 
 it)
	;
	; inputs:
	; (1) [any!] value
	;     the first input is formed to a string, or set to ""
	;   	
	; (2) [object!:font] font to use

 ;     the test will be run with this font, irrelevant of what font 
 is currently set in the face.
	;
	; <TO DO>: add explicit support for /para facet
	;-----------------
	!gfx-text-area: make !plug [
		liquid: 0x0
		
		;-----------------
		;-    frozen?()
		;-----------------
		; plug won't do anything until you have proper linkage done.
		;-----------------
		frozen?: func [
		][
			vin ["" self/valve/type {/frozen?()}]
			vout
			(2 <> length? subordinates)
		]

		valve: make valve [
			;-----------------
			;-    process()
			;-----------------
			process: func [
				plug
				data
			][
				vin ["" self/valve/type {/process()}]
				plug/liquid: 0x0
				glue-proc-face/font: data/2
				glue-proc-face/size: 1000x1000
				glue-proc-face/text: any [
					attempt [to-string data/1]
					""
				]
				plug/liquid: size-text glue-proc-face
				
				vout
			]
			
			
		
		]
	]

Heh.  A bit simpler than the approach I was going to take, that is, 
if it does what you say it does... =D

yep, black text is tested and functional... note the explicit comment 
header

taken strigt out of glue-lib

I think I still don't understand what in particular Liquid is, but 
would it be e.g. good system to do some animation system in? I mean 
- something like Scala. You have some objects, wipes, effects, happening 
at various times, and the might be cross dependant, etc., so that 
when something happens here, something else happens there :-)

Is there a way to hook into the attach function?  I want to build 
a pipe-server that handles multiple values but I want to be able 
to hook up the input plugs in any order and in some cases not have 
a plug for any given value.  To accomplish this I want to create 
a block that tells me which order the plugs are connected in so that 
I can use the index to select the correct plug from the server's 
liquid.

this may be a wild guess, but doesn't the !plug/subordinates do that? 
  I haven't been using pipes so much as links, but I would guess 
you would look at that, and I'd assume the plugs are in the order 
that they have been attached.  Maxim of course will correct me if 
I'm wrong.

Hrm...  I think you're right about that.  Let me look closer at it.

Josh, you are correct.  I can see which node is connected where by 
it's position in the !plug/subordinates block.

Maxim...  I've created all the plugs I need to process each value 
in a font object and they are working beautifully but I'm having 
trouble figuring out what the master !font node should look like. 
 I need to be able to copy changes from each of the nodes handling 
the individual values into an object that I can pass to VID.  Do 
you have any words of wisdom to share on this? ;-)

Ah, what wonders a few hours of rest can work.  I just need to produce 
a plug that takes a series of inputs and converts it into an object. 
 I was overcomplicating things (again...)  When I get back from work 
I'll take another shot at it and this time I think I'll go with a 
dialected approach.

yep ammon that is it.

just one one... pipe servers ARE NOT built to handle multiple values... 
its the opposite.  handling multiple values is done through dependencies 
(linked nodes) all going into one node.

*one note*

pipe servers hanlde multiple view of a single value, coordonating 
everyone so they collaborate in how they share that value.

also note, scanning the subordinates and observers is an extremely 
advanced maneuver... cause the way data is represented in subordinates, 
has different possibilities, for example, you may have word labels 
in the block.  in liquid v2, there will also be possibility to store 
data directly within the subordinates block.  there might, eventually, 
be other uses for the subordinates  I have not yet thought of.

Is there a movie that shows how liquid works?

:)

ie. liquid refreshment

pekr:  yes using liquid interactively is one of its mandates.  the 
liquid editor, will be used in this way, changes will be viewable 
in real-time, so the first set of nodes that are going to be integreated 
are globs, which allows a graphic package to be built within a day.

movies, right now would be really boring, since all that is being 
done, is editing text... but with liquid-vid, and the interactive 
editoe, this will change.

I LIKE the name.

I would abbreviate liquid-vid to just liqvid :-)

Re: Pipe Servers.  I know I'm going to need one, I was just trying 
to combine agregating the font values and serving them.  I need two 
separate nodes for that...

exactly.

all the entry points can be pipes, which are combined into a singular 
node.

I now have the object constructor working well.  I just need to figure 
out the server.  'Tis rather confusing...

IT'S ALIVE!!!!

No pipe server necisarry...

I can just see you with the lightning bolt crackling in the bg and 
a wild look on your face...  hahahaha

Liquid rocks!  I'm getting very close to my goal here and when I 
run into a bug 90% of the time it's because I didn't plug everything 
together properly.  It's pretty sweet.

happy you are "getting" it   :-) it can be a wee bit unsettling when 
the system starts to be knowledgeable about itself.

That's exactly what I want the system to do. =D

my most common bug, is to forget to put something stainless or to 
ask for a value... hehe

I turn round and round and wonder why nothing is being printed on 
the console...  then after a very long time... hehe I realised I 
never asked it to perform its  task... hahaha

The last one I ran across took me 15+ minutes to find a reference 
to face in a plug that never got set.  I couldn't figure out why 
it did nothing...

Sounds like a special tracing/debugging functionality should be included.

it already is  :-)  its run-time switcheable... and its how I always 
find my stuff.  its even indented

if you try out the little blood.r app on rebol.org you'll see how 
extensive liquid's tracing is, thanks to slim's vprint engine.  :-)

plugs also have the generic stats method, which gives A LOT of info 
about the current state of the node.  links, state, type, serial 
numbers, etc.

rmembr that liquid is the culmination of  5, yess FIVE years of R&D 
 ;-)

so for someone who does plain boring data entry forms .. what can 
it do for me?