Liquid Project : connection with datas...

thanks! all the effort is not it vain, then... :-)

you must, of course, open the liquid library and then, in the code, before or after building a liquid-vid layout, you use the attach method to attach one valve to another valve's pipe. example A: valve created after ;----------------------8<-------------------------- rebol [] liquid: open-library 'liquid 0.0.5 lvid: open-library 'liquid-vid 0.0.5 lvid-style: lvid/style ; because VID's layout does not support objects paths... gui: layout [ across styles lvid-style value-sldr: slider 200x20 min 1 max 100 field attach value-sldr 50 ] valve: liquify liquid/valve! [] valve/attach value-sldr/valve ; attach this valve to that slider valve/handle [ print data + 20 ] valve/refill none ; calls an update just on this valve with the pipe's current value. view gui ;-----------------------8<------------------------- example B: valve created before rebol [] liquid: open-library 'liquid 0.0.5 lvid: open-library 'liquid-vid 0.0.5 lvid-style: lvid/style ; because VID's layout does not support objects paths... myvalve: liquify liquid/valve! [ pipe/create handle [print data + 20] ] view layout [ across styles lvid-style fld: field 50 value-sldr: slider 200x20 min 1 max 100 connect myvalve ] ;-----------------------8<------------------------- both code snippets create exactly the same internal setup. -From now on, any change to the slider is updated in the field, any change in the field is updated to the slider. -A print will ALSO be done (value + 20), everytime the value changes. -The field is validated according to slider because it is attached to it. Since validation is persistent, entering a string in the field will reset the field to zero (0). Furthermore, because is uses a more flexible to-integer (steel-utils/as-integer), you can write extra string data (like a %, $, ? even words) and the numeric value in it will still be extracted... rebol's to-integer would just crash. the code. both examples can be further reduced, but it will make it harder to understand so I left them like so. HTH! -MAx

Hi, maybe a bit off-topic but Max, you should pick other words. Even your words are quite creative, there is no hint for someone with IT background what it's all about. Further I think it makes talking about this stuff unnecessary complicated. To me this all looks like a graph. So we have nodes, links or edges, sources and destenations, handle-functions and that's it.

How about such a syntax: gui: layout [ across styles lvid-style sldr: slider 200x20 min 1 max 100 output: field ] edge: link value-sldr/value output/text [ print value + 20 ] IMO much easier to read. Robert

out of the 4 page output of dict valve: From WordNet (r) 2.0 [wn]: valve n 1: a structure in a hollow organ (like the heart) with a flap to insure one-way flow of fluid through it 2: device in a brass wind instrument for varying the length of the air column to alter the pitch of a tone 3: control consisting of a mechanical device for controlling the flow of a fluid I hope that helps ;-) Ingo

LOL, yep, the third is Exactly the meaning DAMN, I should have called it fluid ... not liquid... now I know why everyone is mislead(strangely that was almost the case). thanks for the support Ingo ;-) No, really, liquid stems its name from the term "data flow"... I wanted to make it have its own language so that once assimilated, when following a discussion or especially writting about the relationship a liquid object (or valve) has with the rest of the code, it is clear. when you say "the valve is connected to your object" there is absolutely no ambiguity. One is live, the other isn't. It also stems from the fact that in previous versions of liquid.r there was a base object called container. consider the next phrase: "filling liquid into a container through a pipe", this makes a lot of sense and deftly resumes exactly what is happening. you can thus continue by "if a valve is open, it spills liquid" This being the actual event (or action), depending on what is connected to the valve, will either splash data to the user or silently put it in the container (an object's attribute?), for later reference. I'm sorry this means the methods and attributes have their own "world" but if you think of it, many other programming things have borrowed names from real world items... By looking at the liquid-vid tutorials, http://www.rebol.it/~steel/liquid-vid/tutorials.html Most things about liquid are explained in enough detail, I hope. I have not received one comment on them. either no one went, or those that did, found it clear enough for their understanding (I hope its the later ;-). I understand Robert and Gregg, and I sympathise, but sooo much tought went into it (including other things not yet available) that I feel, its too late. Once you use it a little, you'll see that there isn't alot of words to actually learn and even then, they really are obvious. On top of that, within a liquid-vid block, pretty much only the connect and attach words are needed. I hope that the naming won't keep people from trying it out and understanding the concept. I'm hard at word every other night, hacking away at code that eventually, I hope, you'll all benefit from, much like vanilla, rugby, and make-doc-pro and all the others cool tools. I can't wait for all my tools to be v1.0 but there is soooo much to do. Right now, I am working on the v1.0 of open-library which allows of us to package our code as shared modules. Much like python has a standard code sharing system. Soooooo stay tuned, it won't be long before I submit it for all of us to tear at, bitch about, improve, and eventually adopt. have fun! -MAx ------------- Steel project coordinator http://www.rebol.it/~steel

not received one comment on them. either no one went, or those that did, found it clear enough for their understanding (I hope its the later ;-). I downloaded the zip file from: http://www.rebol.it/~steel/downloads/packages.html then I unzipped Steel so that all the files appeared like this:

== %/c/Rebol/Steel/

colorbox.r library_setup.r liquid-vid.r liquid.r open-library.r sheet-metal_old.r steel-console.r steel-utils.r steel.r Then I added these lines to my %User.r: steel-library-path: [%/C/Rebol/Steel/ %/C/Rebol/Steel/] do %/C/Rebol/Steel/open-library.r That's because I couldn't get %library_setup.r to work properly for me. (It kept making paths to %Steel/Library/ which didn't exist.) Then after running Rebol/View, you need to 'do these lines: liquid-vid: open-library 'liquid-vid 0 stylesheet: liquid-vid/style Then the tutorials at: http://www.rebol.it/~steel/liquid-vid/tutorial-hello.html and: http://www.rebol.it/~steel/liquid-vid/tutorial-slider.html The library part seems very complicated to me. :-/ I don't know what advantage the library system system has over a simple 'do? Steel/Liquid seems really good. Andrew J Martin Steel learning... ICQ: 26227169 http://www.rebol.it/Valley/ http://valley.orcon.net.nz/ http://Valley.150m.com/

That's specifically what you don't have to do, to get at libs. Usually, libs and apps are in separate directories but you can still load the libs, without any knowledge of where they where installed.

weren't you able to delete all paths and browse to new ones ? in any case, this installer was temporary... a completely new lib installer is planned for the new library engine, integrated within the open-library.r equivalent.

the first line ends-up loading several files in one line (liquid.r, steel-console, liquid-vid.r, steel-utils.r) the second one is only needed because of a little shortcomming in vid, in that it does not support object paths anywhere.

basically, you only need to keep a repository of all files you could/need to include in any application, and whenever you need it, it just opens without path. for most small scripts and applets, this is less of a problem since you often only load one or two files which are the backbone of your app. But will all the code I see flying around, I find its a shame that everytime you want to use code from someone else, you have to be sure that it causes no collisions, executes no code behind your back and whatever. the library engine, is an attempt at unifiying the way we share reusable code. If for example, someone has a math lib, he just needs to share it as a standard lib and anyone knows how to get at it. If a unified repository (like rebol.org for example ;-) is available for everyone to put his stuff, then all the files in such a sharable directory would be usable and exclusively safe. no chance of variable or function name clash in any steel library. Basically, everything is stored in an object and when you load a library, your word is set to a new or shared instance of the object stored in the file. all the rebol header is also stored within the object, so you can do some run-time checks. The new library mechanism now also properly supports versioning! You can ask for a minimal version of any shared code. so that when you share your code, if the other person doesn't have the same library in his setup, you can make sure he knows about it. There is much more to the library engine, but I'll wait to release the v1.0 to make an official anouncement and put an exhaustive page on steel's web site... you're right that it is a little overhead compared to just a 'do, but in the end, it makes life simpler, especially if you consider that you can load other things than just shared code in the library. It also lets us share code which uses shared code, without needing to distribute the other code with it. thanks for the feedback, I wish I had more... -MAx