REBOL3 - !Liquid (any questions about liquid dataflow core. [web-public])

Return to Index Page
Most recent messages (300 max) are listed first.

1118Maximvery interesting talk I'll read it to the end its close to my idea for sure :-)18-Sep-09 13:31
1117jockocoming back to your reflexions on a liquid based processing network, it recalls me a distributed code programming language : "wave system", developed in the 90's, and allowing to spread a code in a large and unstructured network for neighbour to neighbour, wher each node executes a part of the code, and provides a part of the information requested, and transmits. It is unfortunately difficult to find info on this system, which was developed by Peter Sapaty. It seems that it was recently used in a light version for network problems studies : "wiseman" , and 6:27
1116MaximI'm really excited... this is probably the furthest I've pushed liquid outside of elixir and so far, its the most stable part of my development cycle. View being at the other end of that spectrum.17-Sep-09 22:16
1115amacleodsounds cool...eager to check out...17-Sep-09 22:10
1114Maximclient work which will be released as open source.17-Sep-09 22:09
1113amacleodwhat do you mean commercial...stuff you have doen for clients or apps you are selling?17-Sep-09 22:08
1112Maximsome commercial stuff using liquid will be released publicly in a short while (within a few weeks maybe sooner).17-Sep-09 21:08
1111jockosounds interesting you intend to do some experiments ? I would also be interested to know if you will release some new examples of liquid.17-Sep-09 21:06
1110MaximI 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.17-Sep-09 20:33
1109RobertTake a look at petri-nets.17-Sep-09 17:35
1108Maximso 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? :-)17-Sep-09 3:56
1107Maximwhenever 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.

17-Sep-09 3:54
1106Maximimagine 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 ;-)

17-Sep-09 3:44
1105Maximits 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. ;-)17-Sep-09 3:41
1104BrianHSounds cool :)17-Sep-09 3:32
1103MaximI 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...

17-Sep-09 3:31
1102Maximposted on remark... release post-poned due to client work. ' :-/6-Jun-09 4:51
1101GrahamDid I miss the roll out?6-Jun-09 4:08
1100MaximI'm working on a completely new site, with more than just programming.2-Jun-09 11:47
1099GerardWill your web site be the actual Steel-toolkit web site or another you will start-up ?2-Jun-09 3:07
1098MaximI 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.28-May-09 2:13
1097GrahamI think he means he might be putting up screen shots ... is that right max?28-May-09 0:10
1096amacleodI'm eager to se what you got, Maxim.27-May-09 23:59
1095Jankocool27-May-09 18:42
1094RobertScongrats !27-May-09 17:51
1093Maximit will be online this week-end... as part of the roll-out of my web site.27-May-09 17:29
1092Jankocan we try or see liquid-paint anywhere :) ?27-May-09 5:56
1091Maxima 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.

27-May-09 2:49
1090RobertS.22-May-09 15:47
1089Maximone reason is that it doesn't map 1:1 plugs are both edges and nodes, for example.9-May-09 17:50
1088RobertI'm pretty sure your concept maps to this.7-May-09 14:29
1087RobertThen extend it by Petri-Net notation using Tokens, Colors etc.7-May-09 14:29
1086RobertMax, I get all this. But how about using the normal graph notation: nodes and edges, direct, undirected, cycles etc.7-May-09 14:29
1085MaximI 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.

7-May-09 4:55
1084Maximrebol 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.

7-May-09 4:53
1083Maximamacleod: I missed your post... just noticed it... don't know why... the color makes it stand out... ' :-/7-May-09 4:39
1082Maximliquid 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.6-May-09 20:32
1081MaartenOne mind trick per evening... latr ;-)6-May-09 20:30
1080Maximhehe.6-May-09 20:30
1079MaartenSee, you're getting it :-)6-May-09 20:30
1078Maxim(no assignments)6-May-09 20:30
1077Maximthat's how liquid works.6-May-09 20:29
1076MaartenSure, can't you?

Or using no assignment?

6-May-09 20:29
1075Maximthere is one thing which liquid needs right now is more examples, more tutorials, but even more, its more liquified modules.6-May-09 20:29
1074Maximcould you imagine writting an application without loops and ifs as the basic control structure?6-May-09 20:28
1073Maximgetting liquid has nothing to do with all of this... its the paradigm which is complex.6-May-09 20:27
1072Maxim1. 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 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.

6-May-09 20:26
1071PekrThis si very well said, I could not say it better :-)6-May-09 11:32
1070RobertIf liquid forces me to use your adapted VID, include-system, libraries etc. your chances are low that I can make use of it.6-May-09 7:56
1069Robert3. 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.6-May-09 7:56
1068Robert2. Simple wording and naming scheme, everything else just confuses everyone. (Your wording is not logical).6-May-09 7:55
1067Robert1. Out of the box example: Download, start, works. No special tools, configs etc.6-May-09 7:55
1066RobertMax, 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:6-May-09 7:54
1065amacleodHow inter connected to rebol is LIQUID...meaning, does rebol make it easier to do this or could it (has it) been done in other languages?6-May-09 3:22
1064Maximok I'm changing color for my nick... its going to "reflect" my constant ramblings about liquid.6-May-09 1:59
1063Maximme too ;-)6-May-09 1:58
1062Jankohm.. sounds mega interesting, I really need to dig into this a little more :)5-May-09 23:47
1061MaximI even want to allow several people to play with individual CVs of a single shape concurrently... its actually harder not to allow it than to let it happen!5-May-09 22:56
1060Maximultimately, to allow all liquified code to interconnect as one seamless system. its already starting. Once I have the network plug done (relatively easy but not yet a priority), things like the collaborative text editors are going to be trivial to code.

I am already working on a collaborative paint concept. where we all draw and manipulate the same canvas without locking!

5-May-09 22:53
1059Maximapplying dataflow to all aspects of computing, not just specialised vertical markets.5-May-09 22:47
1058Mcheanwhat is the problem domain that you are trying to solve with Liquid? Maybe that would help5-May-09 21:02
1057Maximliquid is like the distant philosophical cousing to parse... its strange, magical, makes wonders, but its hard to "get" . ;-)5-May-09 20:43
1056JankoI also looked few times at this, it seems very interesting but I also didn't "get" it :) I will keep trying5-May-09 19:47
1055amacleodI'm in the middle of that very problem (changing an aspect of my interface and having to go through every function that is affected and change them). What you describe sounds awsome.5-May-09 12:55
1054Maximnow if Carl is interested in working with me on making this a reality, I will definitely give some time to the effort. even if we only use liquid for some part of VID it would make a lot of stufff SOOOO much simpler to write afterwards in application, and lazy programming really pays off in terms of economies of processing. in my application, rendering 1 graphic or 100 cause no more processing in most circumstances! only the AGG aspect of things slow down.5-May-09 7:19
1053Maximwe have tried to run liquid within R3 an it crashes rebol... but I didn't have time to figure out why, its a pretty complex object. but I will have to look at in sometime this summer... the simple 10X speed gain of AGG is enough to make it worth, especially since gobs provide internally of what paint simulates in R2.5-May-09 7:15
1052Maximwith liquid, because the system is explicitely defined and dependencies are all resolved at the smallest resolvable value, It took me 4 lines of code to reburbish the whole application... all I needed was to add an an offset to the coordinate system and connect it to 2 other plugs... and every single part of the system now was receiving modified values.5-May-09 7:12
1051Maximusually, you'd need to rebuild the whole system to take the changes into account, or backtrack all functions which interface the coordinates and make sure everyone is using the same values... etc.5-May-09 7:10
1050Maximin the app I am building right now, I'll give you the best example of how powerfull dataflow can be. after developping a complex and interactive canvas, with animation, and stuff... a new spec comes along, that basically changes the coordinate system of the whole engine!!!5-May-09 7:09
1049Maximall you need is a controler which knows what the system is "supposed" to do, set it up... and leave it to run by itself.5-May-09 7:07
1048Maximbut in a sense, API's like paint alleviate a large part of the need for VID. cause the dataset is actually "aware", it doesn't need someone controling it... in fact its aware at such a granular level, than it can actually prevent the majority of processing from happening.5-May-09 7:06
1047MaximI use liquid in VID in R2 almost exclusively.5-May-09 7:04
1046Maximliquid is a kernel. its goal is to manage processing, by using messaging and state at the atomic level. so it can be used by anything, anywhere.5-May-09 7:04
1045PekrMaxim - would it be possible, somehow, to mix Liquid with VID 3.4? Or does it go so deep, that you have to use your won even processing, hence you start at View level, not using VID at all?5-May-09 6:58
1044Maximso you can easily make paint packages like illustrator or custom interfaces which aren't bound to square shapes.5-May-09 6:46
1043MaximI will be releasing the first liquified api shortly, called paint. this is a rebrand of the infamous glob engine. This engine allows people to use draw, just like if it where faces, where individual graphic elements (or groups of them) can receive face-like events.5-May-09 6:45
1042amacleodI would be very interested to see what you can build with it and how its done. Ive looked at the docs briefly but I did not "get it".I should re-read them I guess.5-May-09 2:18
1041MaartenLOL I missed that Liquid was on I thought it was still work in progress :-)4-May-09 16:32
1040Maximwell, it uploading right now, so will be there in afew minutes (3MB upload)4-May-09 14:59
1039Maximliquid is on for the several years has documentaion too... what do you mean? you mean you'd like to play with the application? well YOU now have access to it :-) you know where :-)4-May-09 14:58
1038MaartenIt is really nice, but would be even nicer if we could play with Licquid as well :-) This is teasing!4-May-09 6:00
1037Maximjust wanted to drop a little note saying that I have been using liquid for the last few days developping a brand new application (which I am not at liberty to disclose right now) ...

DAMN... its just soooo sweet... really... adding features is "add and forget". not "pry-in and pray" I have been adding feature after feature, everything is interconnected, graphical, and not only does it allow me to move forward without ever looking back, everything that is liquified in the software is down right unbreakble and bug free.

software source has trippled in size and I have spent only about 4 hours in a whole week's worth of coding for resolving bugs. More news to come in a little while.

3-May-09 14:47
1036Maximas I said, the liquid aspect of it is trivial. its the view aspect... as always. and view is still simpler than most gui engines I've used in the past.18-Apr-09 6:00
1035Maximto get two gui lists to share a dataset, will take as little as two nodes.18-Apr-09 5:59
1034Maximpayof is in: -robustness. there are NO loose ends, no forgetting. its impossible by definition. -long-term dev speedup: adding features doesn't increase complexity, since all features are developped completely independently. -speed: properly designed, lazyness can make an application quite fast, even for very complex apps. obviously, there are worst case scenarios.. like anything. add a dialect in the mix, and then the code size will shrink a lot, but since REBOL itself, isn't dataflow enabled, patching liquid within other REBOL components doesn't really benefit from a dialect. cause creating, connecting and processing nodes is really simple.18-Apr-09 5:58
1033Graham8 nodes?18-Apr-09 5:53
1032Graham16 nodes?18-Apr-09 5:53
1031Maximmost of the time will be spent by me cursing after view trying to get the list to work.18-Apr-09 5:53
1030Grahamso at what point is there a payoff?18-Apr-09 5:53
1029Maximbut no, its not "hard" its just not a 5 line affair.18-Apr-09 5:53
1028Maximand perfect ;-)18-Apr-09 5:52
1027MaximI'd rather say VIEW is the problem. since liquid is pure.18-Apr-09 5:52
1026Maximeasy is a vague term.18-Apr-09 5:51
1025Grahamwhich is what I was saying, it's not easy.18-Apr-09 5:51
1024Maximhum... I seem to be getting the reichart syndrome... there is a *NOT* missing before "really hard".18-Apr-09 5:50
1023Maximmost of the time was spent with non liquid related things... like vid.18-Apr-09 5:50
1022Maximreally hard, I did blood.r which has 16 interconnected fields, in an evening.18-Apr-09 5:49
1021Maximand dataflow is a management layer, so patching a flaky event engine like view's has to be done properly.18-Apr-09 5:49
1020Maximits not easy, because we have to mix three paradigms into one application.18-Apr-09 5:48
1019Maximliquid is not about less code... its about unbreakable and long-term feature creep indiference.18-Apr-09 5:47
1018Grahamso it's not that easy then !18-Apr-09 5:45
1017Maximits easy to do... but right now I am working actually.18-Apr-09 5:43
1016Maximthat will be my next personnal project.. I promise.18-Apr-09 5:43
1015Maximnormally you have to know that whenever the list changes, you have a slew of functions to call, labels to update, what if the cursor changes, due to some insertion, deletion, what if the current selection is deleted... all examples which have to be handled globally... and the more the application grows, the hairier it becomes.18-Apr-09 5:42
1014Grahamyes18-Apr-09 5:42
1013Grahamvid18-Apr-09 5:42
1012Maximdoesn't have to.18-Apr-09 5:41
1011Maximthe advantage, is that there is no "global" understanding of what the data is being used for... each part of an application handles its own use of some data and really isn't aware of the rest of the application, and doesn't care.18-Apr-09 5:41
1010Maximone list might be filtered by gender, another by age, but add a new member to the list, and both will reflect the change... however it happened.18-Apr-09 5:40
1009Maximchange the page number in the field, the scroll bar updates by itself. and vice versa.18-Apr-09 5:39
1008Maximyou could have a decimal range, and have it expressed in other formats, like colors, or sliders, progress bars... but they still all reflect the same original data.18-Apr-09 5:39
1007Maximbut they all share the same string information.18-Apr-09 5:38
1006Maximcause one data might be a string, another an issue, one a word, and still one a tag.18-Apr-09 5:38
1005Maximwhenever one creates a change, that change is performed on the original data set, and everyone is made aware of the new data.18-Apr-09 5:37
1004Grahamso just don't do a copy/deep!18-Apr-09 5:37
1003Maximby "the same data" I don't mean the same rebol block... but the same data in the sense of individuality... they are two different views of the same original data set.18-Apr-09 5:36
1002Maximwell actually, you have to understand, that technically they don't update each other... they really are sharing the same data.18-Apr-09 5:35
1001Maximin vid?18-Apr-09 5:35
1000Grahamhow about a one page example of two text lists upddating each other ?18-Apr-09 5:34
999Maximall you need to do is capture the action, send a message to the relevant liquid. if each control has a liquid which is responsible to set the control, when it receives data, they will update by themselves.18-Apr-09 5:32
998Grahamafterall, it's Rebol, view and data.18-Apr-09 5:30
997MaximI can tell you that its pretty easy to make it work in vid, so it should be pretty easy to make it work in rebgui.18-Apr-09 5:30
996MaximI tried downloading it once and after tortoise svc started fucking up and slowing down my computer, I got fed up, and uninstalled it, and rebgui wen't along with it ... hehe18-Apr-09 5:29
995Grahamcan you make some deductions18-Apr-09 5:29
994Maximexactly. I have never had the need to look at or use rebgui, ever.18-Apr-09 5:28
993Grahamyou're clueless??18-Apr-09 5:28
992Maximrebgui, not a clue.18-Apr-09 5:28
991Maximthey can even have different data in each... as long as its a two-way conversion it would work.18-Apr-09 5:28
990Grahamwhat about rebgui?18-Apr-09 5:28
989Maximchange anyone, they all stay in sync.18-Apr-09 5:27
988Maximyep. you pipe whatever relevant data is creating the gui.18-Apr-09 5:27
987Maximgo.18-Apr-09 5:26
986GrahamIf I maintain copies of data in different gui aspects ... if I update one set at one place, can I automatically update all the other copies?18-Apr-09 5:26
985GrahamI've got a relevant question18-Apr-09 5:26
984Maximjust neighbors complaining, but its ok, I've actually managed to make things worse and solve the direct complaint... hahhaha18-Apr-09 5:25
983Maximactually, I buy all of my digital enternainment. games, DVDs music, etc. I mean, I (have/do/will) live off of all three mediums... so it would be a bit hypocritical for me not to encourage others in my own trades18-Apr-09 5:23
982Grahamplaying your guitar too late and loud at night?18-Apr-09 5:23
981Maximno, its my neighbor.18-Apr-09 5:21
980Grahamwhich songs have you rippped off?18-Apr-09 5:21
979Maximit will happen. in a short while, I just had to stop working on personnal projects for a week or two... life has a tendency to cut into fun stuff... things like lawsuit threats, have a "slight" precedence over me hacking away at a keybord for the sheer fun of it ;-)18-Apr-09 5:18
978Grahamwrite it up again so that those of us who didn't get personal tuition can understand it too!18-Apr-09 5:16
977Maximremember that dataflow is not just about using a new library, its a paradigm change in how you develop and design an application. so most of the difficutly is not in the actual coding of the plugs... which is really easy, its understanding what, how and why they are doing their stuff.18-Apr-09 4:50
976Maximany question you have, just ask here and will help as much as I can. I've tutored three people so far, and it seemed to be easy enough to grasp that within a few hours, they where semi autonomous.18-Apr-09 4:48
975MaximRobert, there are some (old, yet still mostely accurate) docs here:

and specific to the plug (less accurate)

18-Apr-09 4:47
974RobertSMaxim - I have sent you a note on my intent to add to my piece on "slim Liquid Rebol" at eclectic-pencil - I will pen that note in blood ... piping can be so much more feral that ducts ; - )11-Apr-09 14:21
973Ammon 5:41
972Mcheanliquid links?9-Apr-09 23:25
971MaximLiquid has been tested under R3 and crashes it outright. so R3 support for liquid will wait until R3 is a bit more stable, unfortunately. I have enough stuff to debug without having to wonder if its the platform that's causing the bugs in the first place.28-Mar-09 20:25
970Maximalso, liquid-vid project has been dropped, officialy, in favor of putting time on GLASS and GLOB v2 instead.28-Mar-09 20:23
969Maximliquid state of affairs:

-GLASS v1 is going through intense development. -GLUE - foundation plugs, although not yet released is getting packed with fully documented plugs weekly. there is more documentation text than actual code in the lib! *currently working on highly optimised finite state machine systems. (optimised in how they prevent useless processing and messaging).

28-Mar-09 20:22
968Maximliquid v0.8.1 released: changes in this release (from last public release)

v0.7.2 - 8-Mar-2009/21:25:55(MOA) -officially deprecated and REMOVED SHARED-STATES from the whole module -ON-LINK() v0.8.0 - 15-Mar-2009/00:00:00(MOA) -adding stream engine for propagation-style inter-node messaging. -STREAM() added for look-ahead messaging (ask observers to react to us) -ON-STREAM() added to support callbacks when a stream message arrives at a plug. v0.8.1 - 28-Mar-2009/00:00:00(MOA) -PROPAGATE?() added to valve - allows us to optimise lazyness in some advanced plugs -LINK?() regression found and fixed... cycle?() was not being used anymore!

28-Mar-09 20:18
967MaximI myself am building it with faces directly. so its just going to be a quick integration to VID, use of a few facet words and voila.16-Mar-09 16:43
966Maximsomeone could most probably use the same core system and adapt it to rebgui's dialect.16-Mar-09 16:41
965Maximrobert liquid-VID ;-)16-Mar-09 16:39
964RobertOverall, it still sounds like a multi-path constraint solver to me.16-Mar-09 16:07
963RobertOtherwise it's a all-or-nothing thing which makes it hard to bring liquid step-by-step into an existing app.16-Mar-09 16:06
962RobertMax, you should try to find a route to attach liquid to existing GUI like VID or RebGUI. By a dynamic hook or so.16-Mar-09 16:05
961Maximbut once liquid-vid is released... really its going to be very easy to build up grids and a little equation builder.16-Mar-09 15:29
960Maxim:-)16-Mar-09 15:28
959MaximI looked at it a long time ago, but realised that its basically easier to start from scratch... cause if you remove the processing aspect of nano-sheets... there's not much left.16-Mar-09 15:27
958DockimbelMax, would your engine be good fit for a spreadsheet calculation engine? Steve Shireman wrote this nice tiny spreadsheet widget (, I guess that pluging liquid inside would make a killer demo both for liquid and REBOL, don't you think so?16-Mar-09 14:18
957MaximI've been re-designing the wrapper around the system for a week... trying to find a sweetspot between flexibility and styleability.16-Mar-09 9:11
956Maximbtw, the reason liquid-vid is taking some time, is that the whole layout is built using dataflow ! :-)16-Mar-09 9:10
955Maximskining will be dynamic (I mean you plug a color gadget and the whole ui interacts as you set the scheme).16-Mar-09 9:06
954Maximgrids are much easier (actually quite easy) to build with liquid, and in any case, its still faces... so importing a gadget is dooable, if rebgui doesn't depend on too much out of widget infrastructure.16-Mar-09 9:06
953Maximall the label types, will just need one link to a different font.16-Mar-09 9:04
952Maximfor example, in the blood app, there are no int gadgets.16-Mar-09 9:03
951Maximwe don't :-)16-Mar-09 9:02
950Grahamonly if you can replicate all the widgets!16-Mar-09 9:02
949Maximliquid-vid should make glayout and rebgui obsolete.16-Mar-09 9:01
948MaximI also use liquid to build vast networks of AGG graphics for real-time interface creation... we are talking several thousand lines of AGG commands.16-Mar-09 9:00
947Grahamneed to hook this up to rebgui16-Mar-09 8:59
946Maximliquid-vid should provide this out of the box. :-)16-Mar-09 8:59
945Maximif part of a gui, the "submit" button is inactive, until all conditions are met.16-Mar-09 8:58
944Maximan obvious example is a setup where you have a series of inputs, which are all linked to one plug which compiles them as an object.16-Mar-09 8:58
943Maximanything. the example just does artithmetics, bounds and mappings, but you can use this for anything.16-Mar-09 8:57
942Grahamso, this works for numbers and ?16-Mar-09 8:56
941Maximdilute()16-Mar-09 8:54
940MaximI guess we could make a generic dialect which uses a set of pre-determined plugs (a bit like a vid stylesheet) and just builds up a network a bit more easily... this is planned.... the dialect function already has a name.... :-)16-Mar-09 8:54
939Maximdialects will be usefull when the use of the plugs is well defined, and your plugs are pre-defined, then the dialect will effectivey shrink code size by a huge amount... but that's just like for any dialect use.16-Mar-09 8:48
938Maximbut a single function... liquify can actually perform 5 operations in one single line, including linking to any number of pipes at once... so there would actually be very little code gain.16-Mar-09 8:46
937Maximso liquid-vid is going to wrap most of the liquid code for the gui.16-Mar-09 8:45
936Maximthe gross of the work is not in between the plugs... its the plugs themselves.16-Mar-09 8:45
935MaximI have built several systems which used dialects... but liquid allows so much variance, that its like building a dialect for functions...16-Mar-09 8:45
934Maximin theory it should, but in practice, it depends.16-Mar-09 8:44
933Grahamall of this has to be wrapped inside a dialect !16-Mar-09 8:43
932Maximalso note that it was the first time I tried to do this using liquid. its not like an old code sample I refurbished...16-Mar-09 8:36
931Maxim(+/-) are buttons16-Mar-09 8:35
930Maximnotice how it even updates labels, colors, and buttons become inactive when you go out of bounds.16-Mar-09 8:34
929Maximbeurk16-Mar-09 8:34
928Maximits like a sticky fly trap.16-Mar-09 8:34
927Maximwhat really pushed me was that I realized that with gpl, you can even get kicked out of your own code.16-Mar-09 8:33
926Maximall MIT16-Mar-09 8:32
925Grahamis everything MIT now? Is the GPL gone?16-Mar-09 8:32
924Maximtry putting extreme values in ANY field, even non numerical, decimal, etc.16-Mar-09 8:32
923Grahamok, cool . just tried it out16-Mar-09 8:31
922MaximI mean, we have to use liquified versions of things like min/max/sum/sub/append funcs... there is no going around that. but its like defining new functions... which are just as reusable.16-Mar-09 8:30
921Maximwith the external libs I am building (actually working on them daily) code use will be very small. since the most complicated part of the engine will be wrapped within liquid-vid, and you will have a lot of example and reusable liquid classes to start off with.16-Mar-09 8:29
920Maximin this example... way to much, cause we are basically including very basic nodes and a core gui api, but if you remove that, in fact there isn't that much left.16-Mar-09 8:27
919Grahamhow much code is it?16-Mar-09 8:27
918Maximthe entire gui is reflective.16-Mar-09 8:27
917Maximthat's the point of liquid... un breakable.. once it works... it just does16-Mar-09 8:26
916Grahamwaiting for everyone to report their bugs first so that you can fix them :)16-Mar-09 8:26
915Grahamnot yet ... been busy with my pdf stuff.16-Mar-09 8:26
914Maximits a simple download and run... all libs are d/l for you in same dir... can't be easier to try out.16-Mar-09 8:25
913MaximWe already have some variations where the buttons get deactivated even more precisely.16-Mar-09 8:25
912Maximthere are 12 interconnected fields, which all react together. impossible to break by using the gui.16-Mar-09 8:24
911Maximdid you try the blood.r on 8:23
910Grahamscreen validation? calculate results based upon screen entry?16-Mar-09 8:23
909Grahamso for someone who does plain boring data entry forms .. what can it do for me?16-Mar-09 8:23
908Maximrmembr that liquid is the culmination of 5, yess FIVE years of R&D ;-)16-Mar-09 7:51
907Maximplugs 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.16-Mar-09 7:45
906Maximif you try out the little blood.r app on you'll see how extensive liquid's tracing is, thanks to slim's vprint engine. :-)16-Mar-09 7:43
905Maximit already is :-) its run-time switcheable... and its how I always find my stuff. its even indented16-Mar-09 7:43
904RobertSounds like a special tracing/debugging functionality should be included.16-Mar-09 7:40
903AmmonThe 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...16-Mar-09 6:37
902MaximI 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... hahaha16-Mar-09 6:37
901Maximmy most common bug, is to forget to put something stainless or to ask for a value... hehe16-Mar-09 6:36
900AmmonThat's exactly what I want the system to do. =D16-Mar-09 6:33
899Maximhappy you are "getting" it :-) it can be a wee bit unsettling when the system starts to be knowledgeable about itself.16-Mar-09 6:33
898AmmonLiquid 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.16-Mar-09 6:31
897MaximI can just see you with the lightning bolt crackling in the bg and a wild look on your face... hahahaha16-Mar-09 2:23
896AmmonIT'S ALIVE!!!!

No pipe server necisarry...

15-Mar-09 23:50
895AmmonI now have the object constructor working well. I just need to figure out the server. 'Tis rather confusing...15-Mar-09 22:06
894Maximall the entry points can be pipes, which are combined into a singular node.15-Mar-09 2:38
893Maximexactly.15-Mar-09 2:37
892AmmonRe: 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...15-Mar-09 0:39
891PekrI would abbreviate liquid-vid to just liqvid :-)14-Mar-09 19:50
890MaximI LIKE the name.14-Mar-09 19:16
889Maximmovies, 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.14-Mar-09 19:16
888Maximpekr: 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.14-Mar-09 19:15
887Grahamie. liquid refreshment14-Mar-09 19:15
886Graham:)14-Mar-09 19:15
885GrahamIs there a movie that shows how liquid works?14-Mar-09 19:14
884Maximalso 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.14-Mar-09 19:13
883Maximpipe servers hanlde multiple view of a single value, coordonating everyone so they collaborate in how they share that value.14-Mar-09 18:22
882Maxim*one note*14-Mar-09 18:22
881Maximjust 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.14-Mar-09 18:21
880Maximyep ammon that is it.14-Mar-09 18:20
879AmmonAh, 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.14-Mar-09 13:46
878AmmonMaxim... 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? ;-)14-Mar-09 7:26
877AmmonJosh, you are correct. I can see which node is connected where by it's position in the !plug/subordinates block.14-Mar-09 7:22
876AmmonHrm... I think you're right about that. Let me look closer at it.14-Mar-09 5:05
875Joshthis 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.14-Mar-09 5:02
874AmmonIs 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.14-Mar-09 3:33
873PekrI 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 :-)13-Mar-09 19:37
872Maximtaken strigt out of glue-lib13-Mar-09 7:29
871Maximyep, black text is tested and functional... note the explicit comment header13-Mar-09 7:28
870AmmonHeh. A bit simpler than the approach I was going to take, that is, if it does what you say it does... =D13-Mar-09 7:28
869Maxim------------------------------------------------- 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 ] ] ]

13-Mar-09 7:24
868AmmonWTF?!? How did you do it? This is EXACTLY what I've been working on!13-Mar-09 7:21
867Maximglue now has a plug that returns gfx text size given any value and a font :-)13-Mar-09 7:20
866Maxima subtle but extremely powerfull and explicit demonstration of dataflow robustness.13-Mar-09 7:07
865Maximso the field just inherits that behaviour FROM the character WITHOUT ANY SINGLE LINE OF CODE it became an integer field.13-Mar-09 7:06
864Maximno matter how you try to set the ability, IT will always be clamped... there is no way to break it.13-Mar-09 7:05
863Maximnotice that the integer range is not applied to the field... its applied to the ABILITY.13-Mar-09 7:05
862Maximthe most basic thing to understand about liquid is that the central part of any application is not the interface... its the DATA.13-Mar-09 7:04
861Maximcool :-)13-Mar-09 7:04
860Maximknow = now13-Mar-09 7:04
859AmmonOk. I think I'm starting to see what you are doing with pipes. Some of the voodoo in Blood.r isn't as mystical as it was a few minutes ago. ;-)13-Mar-09 7:04
858Maximand strangely, you guys are all pretty much evolving and learning in about the same pattern... so I have some clues into how to order the tutorials. :-)13-Mar-09 7:04
857MaximI know have a pretty good idea of recurring topics.13-Mar-09 7:03
856MaximI will start building explicit tutorials this week end.13-Mar-09 7:03
855Maximbtw, when we are working with pipes, we use the attach and detach functions instead of link/unlink.13-Mar-09 7:02
854Maximone important note, is that switching computation modes, NEVER unlinks previous subordinates... it will only ignore them. only the pipe aspect is dynamic and can be unlinked automatically by the internal plug managers...13-Mar-09 7:01
853MaximThe computing methods mutation is one of the most powerfull and unique aspects of liquid. the same plug can be used for many different purposes, and it can go to-from any method to another.13-Mar-09 7:00
852Maximthe pipe server can be used to normalise the data into its purest form, and allows many things in your application to interact with it as peers. one can be a string another an int. but for each pipe client, they could care less about who and what the others are. they just need to know that, in this case, they are always receiving an int, and can convert it back to the format they need.13-Mar-09 6:58
851Maximnote that when you fill a pipe server through a node... even that node receives the data back.13-Mar-09 6:56
850Maximlinked-containers, accumulate their subordinate data AND add the value you filled , as if it where an extra link... which then goes through the normal process mechanism.13-Mar-09 6:56
849Maximnote that you can LINK the pipe server and set it to a linked-container? too! but that is advanced usage.13-Mar-09 6:55
848Maxim(sorry, define the purify function on it)13-Mar-09 6:54
847Maximthe pipe server thus serves as an in-between. the fact that its also a plug makes it very flexible, since you can call the purify function on it.13-Mar-09 6:54
846Maximpipes work in about the same way, but every time a value is filled within a piped plug, ALL of the other members of that pipe ALSO get filled with the same value.13-Mar-09 6:53
845Maximyour plug simply stores a value and returns it (but purify IS still called on it)13-Mar-09 6:52
844Maximplugs may be filled with data directly. when you do this the node becomes a container, and this effectively turns off all of the linking management..13-Mar-09 6:52
843Maximbut no two values may intercommunicate.13-Mar-09 6:50
842Maximlinked nodes will ask their "subordinates" about their values... this starts a recursive chain reaction, until all subordinates of all subordinates have cleaned up.13-Mar-09 6:50
841AmmonYeah, I figured that last part out.13-Mar-09 6:49
840Maximto tell the system what node to allocate, you preset the pipe-server-class in advance, so it knows what kind of pipe you want.13-Mar-09 6:49
839AmmonOk... So, what's the difference between a pipe and a link? >;)13-Mar-09 6:49
838Maximthis allows you to normalize the values amongst all piped nodes. since, you can redefine that plug, like any other.13-Mar-09 6:48
837Maximthis is a normal plug to which all plugs are linked, via the pipe? attribute.13-Mar-09 6:48
836Maximwhen you pipe two or more nodes together (using pipe() on a plug, using the /piped refinement of liquify, or fill/pipe) the system automatically creates a pipe server which acts as a broker amongst all piped plugs.13-Mar-09 6:47
835AmmonIt's not clear why you created the !int-range-srv plug for Blood.r rather than just creating !int-range directly.13-Mar-09 6:45
834Maximfor the layout algorythm, I actualy did a complete flow analysis of a row/column resizing liquid graph. its actually rather simple, when you force yourself to follow what data goes where. note that I was able to build this without creating a processing cycle... which is neat, since some values are going to the parent face and coming back to its pane elements.13-Mar-09 5:28
833Maximanyone who wants to get to use liquid, don't hesitate to try and ask stupid questions. They are hard to answer, and its giving me a chance to get a general feeling of what needs more attention in the forthcomming revision to the whole liquid documentation.13-Mar-09 5:21
832AmmonCongrats!13-Mar-09 5:20
831AmmonOh, my bad. It's not in Blood.r. It's in the code you posted above for the !color node...13-Mar-09 5:20
830Maximyou guys can't imagine how nice it feels to be discussing and teaching about how to use liquid.... I've now got three pupils... in one week... that's so cool...13-Mar-09 5:20
829AmmonLOL13-Mar-09 5:19
828Maximdarn, even I was using it upside down in many plugs, in other stuff! hehe I guess I should learn to RTFM... especially when I writing it! ;-)13-Mar-09 5:15
827Maximstrange I can't find that specific code in blood.r... I guess I already fixed here, hehe.13-Mar-09 5:14
826AmmonFixed. Sweet!13-Mar-09 5:13
825Maximyep... I WILL13-Mar-09 5:12
824Maximhahaha13-Mar-09 5:12
823AmmonLOL, fix blood.r then, please!

; 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

13-Mar-09 5:12
822MaximI might have described it the other way around, but I meant to say like its described in the above sentence... sorry if I mislead you!13-Mar-09 5:11
821Maximfrom the liquid code's purify documentation (in the code)

; we RETURN if this plug can be considered dirty or not at this point.

so if you return true, it remains dirty.

13-Mar-09 5:11
820Ammonc: liquify !color13-Mar-09 5:06
819Maximuse liquify first.13-Mar-09 5:06

Return to Index Page