| # | User | Message | Date |
| 1118 | Maxim | very interesting talk I'll read it to the end its close to my idea for sure :-) | 18-Sep-09 13:31 |
| 1117 | jocko | coming 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" http://www.ece.ubc.ca/~vleung/IWCMC2008%20Keynote%20VLeung.pdf , and http://www.ece.ubc.ca/~sergiog/wiseman/WisemanManual.pdf | 18-Sep-09 6:27 |
| 1116 | Maxim | I'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 |
| 1115 | amacleod | sounds cool...eager to check out... | 17-Sep-09 22:10 |
| 1114 | Maxim | client work which will be released as open source. | 17-Sep-09 22:09 |
| 1113 | amacleod | what do you mean commercial...stuff you have doen for clients or apps you are selling? | 17-Sep-09 22:08 |
| 1112 | Maxim | some commercial stuff using liquid will be released publicly in a short while (within a few weeks maybe sooner). | 17-Sep-09 21:08 |
| 1111 | jocko | sounds interesting ...do 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 |
| 1110 | Maxim | I 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 |
| 1109 | Robert | Take a look at petri-nets. | 17-Sep-09 17:35 |
| 1108 | Maxim | so 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 |
| 1107 | Maxim | whenever 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 |
| 1106 | Maxim | imagine 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 |
| 1105 | Maxim | its 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 |
| 1104 | BrianH | Sounds cool :) | 17-Sep-09 3:32 |
| 1103 | Maxim | I 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 |
| 1102 | Maxim | posted on remark... release post-poned due to client work. ' :-/ | 6-Jun-09 4:51 |
| 1101 | Graham | Did I miss the roll out? | 6-Jun-09 4:08 |
| 1100 | Maxim | I'm working on a completely new site, with more than just programming. | 2-Jun-09 11:47 |
| 1099 | Gerard | Will your web site be the actual Steel-toolkit web site or another you will start-up ? | 2-Jun-09 3:07 |
| 1098 | Maxim | I 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 |
| 1097 | Graham | I think he means he might be putting up screen shots ... is that right max? | 28-May-09 0:10 |
| 1096 | amacleod | I'm eager to se what you got, Maxim. | 27-May-09 23:59 |
| 1095 | Janko | cool | 27-May-09 18:42 |
| 1094 | RobertS | congrats ! | 27-May-09 17:51 |
| 1093 | Maxim | it will be online this week-end... as part of the roll-out of my web site. | 27-May-09 17:29 |
| 1092 | Janko | can we try or see liquid-paint anywhere :) ? | 27-May-09 5:56 |
| 1091 | Maxim | a 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 |
| 1090 | RobertS | . | 22-May-09 15:47 |
| 1089 | Maxim | one reason is that it doesn't map 1:1 plugs are both edges and nodes, for example. | 9-May-09 17:50 |
| 1088 | Robert | I'm pretty sure your concept maps to this. | 7-May-09 14:29 |
| 1087 | Robert | Then extend it by Petri-Net notation using Tokens, Colors etc. | 7-May-09 14:29 |
| 1086 | Robert | Max, I get all this. But how about using the normal graph notation: nodes and edges, direct, undirected, cycles etc. | 7-May-09 14:29 |
| 1085 | Maxim | I 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 |
| 1084 | Maxim | rebol 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 |
| 1083 | Maxim | amacleod: I missed your post... just noticed it... don't know why... the color makes it stand out... ' :-/ | 7-May-09 4:39 |
| 1082 | Maxim | liquid 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 |
| 1081 | Maarten | One mind trick per evening... latr ;-) | 6-May-09 20:30 |
| 1080 | Maxim | hehe. | 6-May-09 20:30 |
| 1079 | Maarten | See, you're getting it :-) | 6-May-09 20:30 |
| 1078 | Maxim | (no assignments) | 6-May-09 20:30 |
| 1077 | Maxim | that's how liquid works. | 6-May-09 20:29 |
| 1076 | Maarten | Sure, can't you? Or using no assignment? | 6-May-09 20:29 |
| 1075 | Maxim | there 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 |
| 1074 | Maxim | could you imagine writting an application without loops and ifs as the basic control structure? | 6-May-09 20:28 |
| 1073 | Maxim | getting liquid has nothing to do with all of this... its the paradigm which is complex. | 6-May-09 20:27 |
| 1072 | Maxim | 1. 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 rebo.org 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 |
| 1071 | Pekr | This si very well said, I could not say it better :-) | 6-May-09 11:32 |
| 1070 | Robert | If 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 |
| 1069 | Robert | 3. 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 |
| 1068 | Robert | 2. Simple wording and naming scheme, everything else just confuses everyone. (Your wording is not logical). | 6-May-09 7:55 |
| 1067 | Robert | 1. Out of the box example: Download, start, works. No special tools, configs etc. | 6-May-09 7:55 |
| 1066 | Robert | Max, 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 |
| 1065 | amacleod | How 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 |
| 1064 | Maxim | ok I'm changing color for my nick... its going to "reflect" my constant ramblings about liquid. | 6-May-09 1:59 |
| 1063 | Maxim | me too ;-) | 6-May-09 1:58 |
| 1062 | Janko | hm.. sounds mega interesting, I really need to dig into this a little more :) | 5-May-09 23:47 |
| 1061 | Maxim | I 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 |
| 1060 | Maxim | ultimately, 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 |
| 1059 | Maxim | applying dataflow to all aspects of computing, not just specialised vertical markets. | 5-May-09 22:47 |
| 1058 | Mchean | what is the problem domain that you are trying to solve with Liquid? Maybe that would help | 5-May-09 21:02 |
| 1057 | Maxim | liquid is like the distant philosophical cousing to parse... its strange, magical, makes wonders, but its hard to "get" . ;-) | 5-May-09 20:43 |
| 1056 | Janko | I also looked few times at this, it seems very interesting but I also didn't "get" it :) I will keep trying | 5-May-09 19:47 |
| 1055 | amacleod | I'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 |
| 1054 | Maxim | now 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 |
| 1053 | Maxim | we 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 |
| 1052 | Maxim | with 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 |
| 1051 | Maxim | usually, 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 |
| 1050 | Maxim | in 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 |
| 1049 | Maxim | all 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 |
| 1048 | Maxim | but 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 |
| 1047 | Maxim | I use liquid in VID in R2 almost exclusively. | 5-May-09 7:04 |
| 1046 | Maxim | liquid 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 |
| 1045 | Pekr | Maxim - 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 |
| 1044 | Maxim | so you can easily make paint packages like illustrator or custom interfaces which aren't bound to square shapes. | 5-May-09 6:46 |
| 1043 | Maxim | I 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 |
| 1042 | amacleod | I 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 |
| 1041 | Maarten | LOL I missed that Liquid was on rebol.org. I thought it was still work in progress :-) | 4-May-09 16:32 |
| 1040 | Maxim | well, it uploading right now, so will be there in afew minutes (3MB upload) | 4-May-09 14:59 |
| 1039 | Maxim | liquid is on rebol.org 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 |
| 1038 | Maarten | It is really nice, but would be even nicer if we could play with Licquid as well :-) This is teasing! | 4-May-09 6:00 |
| 1037 | Maxim | just 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 |
| 1036 | Maxim | as 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 |
| 1035 | Maxim | to get two gui lists to share a dataset, will take as little as two nodes. | 18-Apr-09 5:59 |
| 1034 | Maxim | payof 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 |
| 1033 | Graham | 8 nodes? | 18-Apr-09 5:53 |
| 1032 | Graham | 16 nodes? | 18-Apr-09 5:53 |
| 1031 | Maxim | most of the time will be spent by me cursing after view trying to get the list to work. | 18-Apr-09 5:53 |
| 1030 | Graham | so at what point is there a payoff? | 18-Apr-09 5:53 |
| 1029 | Maxim | but no, its not "hard" its just not a 5 line affair. | 18-Apr-09 5:53 |
| 1028 | Maxim | and perfect ;-) | 18-Apr-09 5:52 |
| 1027 | Maxim | I'd rather say VIEW is the problem. since liquid is pure. | 18-Apr-09 5:52 |
| 1026 | Maxim | easy is a vague term. | 18-Apr-09 5:51 |
| 1025 | Graham | which is what I was saying, it's not easy. | 18-Apr-09 5:51 |
| 1024 | Maxim | hum... I seem to be getting the reichart syndrome... there is a *NOT* missing before "really hard". | 18-Apr-09 5:50 |
| 1023 | Maxim | most of the time was spent with non liquid related things... like vid. | 18-Apr-09 5:50 |
| 1022 | Maxim | really hard, I did blood.r which has 16 interconnected fields, in an evening. | 18-Apr-09 5:49 |
| 1021 | Maxim | and dataflow is a management layer, so patching a flaky event engine like view's has to be done properly. | 18-Apr-09 5:49 |
| 1020 | Maxim | its not easy, because we have to mix three paradigms into one application. | 18-Apr-09 5:48 |
| 1019 | Maxim | liquid is not about less code... its about unbreakable and long-term feature creep indiference. | 18-Apr-09 5:47 |
| 1018 | Graham | so it's not that easy then ! | 18-Apr-09 5:45 |
| 1017 | Maxim | its easy to do... but right now I am working actually. | 18-Apr-09 5:43 |
| 1016 | Maxim | that will be my next personnal project.. I promise. | 18-Apr-09 5:43 |
| 1015 | Maxim | normally 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 |
| 1014 | Graham | yes | 18-Apr-09 5:42 |
| 1013 | Graham | vid | 18-Apr-09 5:42 |
| 1012 | Maxim | doesn't have to. | 18-Apr-09 5:41 |
| 1011 | Maxim | the 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 |
| 1010 | Maxim | one 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 |
| 1009 | Maxim | change the page number in the field, the scroll bar updates by itself. and vice versa. | 18-Apr-09 5:39 |
| 1008 | Maxim | you 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 |
| 1007 | Maxim | but they all share the same string information. | 18-Apr-09 5:38 |
| 1006 | Maxim | cause one data might be a string, another an issue, one a word, and still one a tag. | 18-Apr-09 5:38 |
| 1005 | Maxim | whenever 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 |
| 1004 | Graham | so just don't do a copy/deep! | 18-Apr-09 5:37 |
| 1003 | Maxim | by "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 |
| 1002 | Maxim | well 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 |
| 1001 | Maxim | in vid? | 18-Apr-09 5:35 |
| 1000 | Graham | how about a one page example of two text lists upddating each other ? | 18-Apr-09 5:34 |
| 999 | Maxim | all 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 |
| 998 | Graham | afterall, it's Rebol, view and data. | 18-Apr-09 5:30 |
| 997 | Maxim | I 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 |
| 996 | Maxim | I 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 ... hehe | 18-Apr-09 5:29 |
| 995 | Graham | can you make some deductions | 18-Apr-09 5:29 |
| 994 | Maxim | exactly. I have never had the need to look at or use rebgui, ever. | 18-Apr-09 5:28 |
| 993 | Graham | you're clueless?? | 18-Apr-09 5:28 |
| 992 | Maxim | rebgui, not a clue. | 18-Apr-09 5:28 |
| 991 | Maxim | they can even have different data in each... as long as its a two-way conversion it would work. | 18-Apr-09 5:28 |
| 990 | Graham | what about rebgui? | 18-Apr-09 5:28 |
| 989 | Maxim | change anyone, they all stay in sync. | 18-Apr-09 5:27 |
| 988 | Maxim | yep. you pipe whatever relevant data is creating the gui. | 18-Apr-09 5:27 |
| 987 | Maxim | go. | 18-Apr-09 5:26 |
| 986 | Graham | If 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 |
| 985 | Graham | I've got a relevant question | 18-Apr-09 5:26 |
| 984 | Maxim | just neighbors complaining, but its ok, I've actually managed to make things worse and solve the direct complaint... hahhaha | 18-Apr-09 5:25 |
| 983 | Maxim | actually, 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 trades | 18-Apr-09 5:23 |
| 982 | Graham | playing your guitar too late and loud at night? | 18-Apr-09 5:23 |
| 981 | Maxim | no, its my neighbor. | 18-Apr-09 5:21 |
| 980 | Graham | which songs have you rippped off? | 18-Apr-09 5:21 |
| 979 | Maxim | it 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 |
| 978 | Graham | write it up again so that those of us who didn't get personal tuition can understand it too! | 18-Apr-09 5:16 |
| 977 | Maxim | remember 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 |
| 976 | Maxim | any 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 |
| 975 | Maxim | Robert, there are some (old, yet still mostely accurate) docs here:
http://www.pointillistic.com/open-REBOL/moa/steel/liquid/index.html and specific to the plug (less accurate) http://www.pointillistic.com/open-REBOL/moa/steel/liquid/plug/index.html | 18-Apr-09 4:47 |
| 974 | RobertS | Maxim - 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 |
| 973 | Ammon | http://www.rebol.org/view-script.r?script=liquid.r | 10-Apr-09 5:41 |
| 972 | Mchean | liquid links? | 9-Apr-09 23:25 |
| 971 | Maxim | Liquid 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 |
| 970 | Maxim | also, liquid-vid project has been dropped, officialy, in favor of putting time on GLASS and GLOB v2 instead. | 28-Mar-09 20:23 |
| 969 | Maxim | liquid 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 |
| 968 | Maxim | liquid 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 |
| 967 | Maxim | I 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 |
| 966 | Maxim | someone could most probably use the same core system and adapt it to rebgui's dialect. | 16-Mar-09 16:41 |
| 965 | Maxim | robert liquid-VID ;-) | 16-Mar-09 16:39 |
| 964 | Robert | Overall, it still sounds like a multi-path constraint solver to me. | 16-Mar-09 16:07 |
| 963 | Robert | Otherwise 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 |
| 962 | Robert | Max, 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 |
| 961 | Maxim | but 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 |
| 960 | Maxim | :-) | 16-Mar-09 15:28 |
| 959 | Maxim | I 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 |
| 958 | Dockimbel | Max, would your engine be good fit for a spreadsheet calculation engine? Steve Shireman wrote this nice tiny spreadsheet widget (http://www.efishantsea.com/nano-sheets.zip), 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 |
| 957 | Maxim | I'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 |
| 956 | Maxim | btw, the reason liquid-vid is taking some time, is that the whole layout is built using dataflow ! :-) | 16-Mar-09 9:10 |
| 955 | Maxim | skining 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 |
| 954 | Maxim | grids 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 |
| 953 | Maxim | all the label types, will just need one link to a different font. | 16-Mar-09 9:04 |
| 952 | Maxim | for example, in the blood app, there are no int gadgets. | 16-Mar-09 9:03 |
| 951 | Maxim | we don't :-) | 16-Mar-09 9:02 |
| 950 | Graham | only if you can replicate all the widgets! | 16-Mar-09 9:02 |
| 949 | Maxim | liquid-vid should make glayout and rebgui obsolete. | 16-Mar-09 9:01 |
| 948 | Maxim | I 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 |
| 947 | Graham | need to hook this up to rebgui | 16-Mar-09 8:59 |
| 946 | Maxim | liquid-vid should provide this out of the box. :-) | 16-Mar-09 8:59 |
| 945 | Maxim | if part of a gui, the "submit" button is inactive, until all conditions are met. | 16-Mar-09 8:58 |
| 944 | Maxim | an 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 |
| 943 | Maxim | anything. the example just does artithmetics, bounds and mappings, but you can use this for anything. | 16-Mar-09 8:57 |
| 942 | Graham | so, this works for numbers and ? | 16-Mar-09 8:56 |
| 941 | Maxim | dilute() | 16-Mar-09 8:54 |
| 940 | Maxim | I 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 |
| 939 | Maxim | dialects 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 |
| 938 | Maxim | but 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 |
| 937 | Maxim | so liquid-vid is going to wrap most of the liquid code for the gui. | 16-Mar-09 8:45 |
| 936 | Maxim | the gross of the work is not in between the plugs... its the plugs themselves. | 16-Mar-09 8:45 |
| 935 | Maxim | I 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 |
| 934 | Maxim | in theory it should, but in practice, it depends. | 16-Mar-09 8:44 |
| 933 | Graham | all of this has to be wrapped inside a dialect ! | 16-Mar-09 8:43 |
| 932 | Maxim | also 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 |
| 931 | Maxim | (+/-) are buttons | 16-Mar-09 8:35 |
| 930 | Maxim | notice how it even updates labels, colors, and buttons become inactive when you go out of bounds. | 16-Mar-09 8:34 |
| 929 | Maxim | beurk | 16-Mar-09 8:34 |
| 928 | Maxim | its like a sticky fly trap. | 16-Mar-09 8:34 |
| 927 | Maxim | what 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 |
| 926 | Maxim | all MIT | 16-Mar-09 8:32 |
| 925 | Graham | is everything MIT now? Is the GPL gone? | 16-Mar-09 8:32 |
| 924 | Maxim | try putting extreme values in ANY field, even non numerical, decimal, etc. | 16-Mar-09 8:32 |
| 923 | Graham | ok, cool . just tried it out | 16-Mar-09 8:31 |
| 922 | Maxim | I 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 |
| 921 | Maxim | with 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 |
| 920 | Maxim | in 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 |
| 919 | Graham | how much code is it? | 16-Mar-09 8:27 |
| 918 | Maxim | the entire gui is reflective. | 16-Mar-09 8:27 |
| 917 | Maxim | that's the point of liquid... un breakable.. once it works... it just does | 16-Mar-09 8:26 |
| 916 | Graham | waiting for everyone to report their bugs first so that you can fix them :) | 16-Mar-09 8:26 |
| 915 | Graham | not yet ... been busy with my pdf stuff. | 16-Mar-09 8:26 |
| 914 | Maxim | its 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 |
| 913 | Maxim | We already have some variations where the buttons get deactivated even more precisely. | 16-Mar-09 8:25 |
| 912 | Maxim | there are 12 interconnected fields, which all react together. impossible to break by using the gui. | 16-Mar-09 8:24 |
| 911 | Maxim | did you try the blood.r on rebol.org? | 16-Mar-09 8:23 |
| 910 | Graham | screen validation? calculate results based upon screen entry? | 16-Mar-09 8:23 |
| 909 | Graham | so for someone who does plain boring data entry forms .. what can it do for me? | 16-Mar-09 8:23 |
| 908 | Maxim | rmembr that liquid is the culmination of 5, yess FIVE years of R&D ;-) | 16-Mar-09 7:51 |
| 907 | Maxim | 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. | 16-Mar-09 7:45 |
| 906 | Maxim | 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. :-) | 16-Mar-09 7:43 |
| 905 | Maxim | it already is :-) its run-time switcheable... and its how I always find my stuff. its even indented | 16-Mar-09 7:43 |
| 904 | Robert | Sounds like a special tracing/debugging functionality should be included. | 16-Mar-09 7:40 |
| 903 | Ammon | 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... | 16-Mar-09 6:37 |
| 902 | Maxim | 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 | 16-Mar-09 6:37 |
| 901 | Maxim | my most common bug, is to forget to put something stainless or to ask for a value... hehe | 16-Mar-09 6:36 |
| 900 | Ammon | That's exactly what I want the system to do. =D | 16-Mar-09 6:33 |
| 899 | Maxim | happy 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 |
| 898 | Ammon | 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. | 16-Mar-09 6:31 |
| 897 | Maxim | I can just see you with the lightning bolt crackling in the bg and a wild look on your face... hahahaha | 16-Mar-09 2:23 |
| 896 | Ammon | IT'S ALIVE!!!! No pipe server necisarry... | 15-Mar-09 23:50 |
| 895 | Ammon | I now have the object constructor working well. I just need to figure out the server. 'Tis rather confusing... | 15-Mar-09 22:06 |
| 894 | Maxim | all the entry points can be pipes, which are combined into a singular node. | 15-Mar-09 2:38 |
| 893 | Maxim | exactly. | 15-Mar-09 2:37 |
| 892 | Ammon | 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... | 15-Mar-09 0:39 |
| 891 | Pekr | I would abbreviate liquid-vid to just liqvid :-) | 14-Mar-09 19:50 |
| 890 | Maxim | I LIKE the name. | 14-Mar-09 19:16 |
| 889 | Maxim | 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. | 14-Mar-09 19:16 |
| 888 | Maxim | 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. | 14-Mar-09 19:15 |
| 887 | Graham | ie. liquid refreshment | 14-Mar-09 19:15 |
| 886 | Graham | :) | 14-Mar-09 19:15 |
| 885 | Graham | Is there a movie that shows how liquid works? | 14-Mar-09 19:14 |
| 884 | Maxim | 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. | 14-Mar-09 19:13 |
| 883 | Maxim | pipe servers hanlde multiple view of a single value, coordonating everyone so they collaborate in how they share that value. | 14-Mar-09 18:22 |
| 882 | Maxim | *one note* | 14-Mar-09 18:22 |
| 881 | Maxim | 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. | 14-Mar-09 18:21 |
| 880 | Maxim | yep ammon that is it. | 14-Mar-09 18:20 |
| 879 | Ammon | 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. | 14-Mar-09 13:46 |
| 878 | Ammon | 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? ;-) | 14-Mar-09 7:26 |
| 877 | Ammon | Josh, 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 |
| 876 | Ammon | Hrm... I think you're right about that. Let me look closer at it. | 14-Mar-09 5:05 |
| 875 | Josh | 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. | 14-Mar-09 5:02 |
| 874 | Ammon | 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. | 14-Mar-09 3:33 |
| 873 | Pekr | 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 :-) | 13-Mar-09 19:37 |
| 872 | Maxim | taken strigt out of glue-lib | 13-Mar-09 7:29 |
| 871 | Maxim | yep, black text is tested and functional... note the explicit comment header | 13-Mar-09 7:28 |
| 870 | Ammon | Heh. A bit simpler than the approach I was going to take, that is, if it does what you say it does... =D | 13-Mar-09 7:28 |
| 869 | Maxim | -------------------------------------------------
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 |
| 868 | Ammon | WTF?!? How did you do it? This is EXACTLY what I've been working on! | 13-Mar-09 7:21 |
| 867 | Maxim | glue now has a plug that returns gfx text size given any value and a font :-) | 13-Mar-09 7:20 |
| 866 | Maxim | a subtle but extremely powerfull and explicit demonstration of dataflow robustness. | 13-Mar-09 7:07 |
| 865 | Maxim | so 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 |
| 864 | Maxim | no 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 |
| 863 | Maxim | notice that the integer range is not applied to the field... its applied to the ABILITY. | 13-Mar-09 7:05 |
| 862 | Maxim | the 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 |
| 861 | Maxim | cool :-) | 13-Mar-09 7:04 |
| 860 | Maxim | know = now | 13-Mar-09 7:04 |
| 859 | Ammon | Ok. 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 |
| 858 | Maxim | and 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 |
| 857 | Maxim | I know have a pretty good idea of recurring topics. | 13-Mar-09 7:03 |
| 856 | Maxim | I will start building explicit tutorials this week end. | 13-Mar-09 7:03 |
| 855 | Maxim | btw, when we are working with pipes, we use the attach and detach functions instead of link/unlink. | 13-Mar-09 7:02 |
| 854 | Maxim | one 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 |
| 853 | Maxim | The 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 |
| 852 | Maxim | the 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 |
| 851 | Maxim | note that when you fill a pipe server through a node... even that node receives the data back. | 13-Mar-09 6:56 |
| 850 | Maxim | linked-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 |
| 849 | Maxim | note 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 |
| 848 | Maxim | (sorry, define the purify function on it) | 13-Mar-09 6:54 |
| 847 | Maxim | the 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 |
| 846 | Maxim | pipes 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 |
| 845 | Maxim | your plug simply stores a value and returns it (but purify IS still called on it) | 13-Mar-09 6:52 |
| 844 | Maxim | plugs 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 |
| 843 | Maxim | but no two values may intercommunicate. | 13-Mar-09 6:50 |
| 842 | Maxim | linked 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 |
| 841 | Ammon | Yeah, I figured that last part out. | 13-Mar-09 6:49 |
| 840 | Maxim | to 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 |
| 839 | Ammon | Ok... So, what's the difference between a pipe and a link? >;) | 13-Mar-09 6:49 |
| 838 | Maxim | this allows you to normalize the values amongst all piped nodes. since, you can redefine that plug, like any other. | 13-Mar-09 6:48 |
| 837 | Maxim | this is a normal plug to which all plugs are linked, via the pipe? attribute. | 13-Mar-09 6:48 |
| 836 | Maxim | when 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 |
| 835 | Ammon | It'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 |
| 834 | Maxim | for 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 |
| 833 | Maxim | anyone 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 |
| 832 | Ammon | Congrats! | 13-Mar-09 5:20 |
| 831 | Ammon | Oh, 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 |
| 830 | Maxim | you 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 |
| 829 | Ammon | LOL | 13-Mar-09 5:19 |
| 828 | Maxim | darn, 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 |
| 827 | Maxim | strange I can't find that specific code in blood.r... I guess I already fixed here, hehe. | 13-Mar-09 5:14 |
| 826 | Ammon | Fixed. Sweet! | 13-Mar-09 5:13 |
| 825 | Maxim | yep... I WILL | 13-Mar-09 5:12 |
| 824 | Maxim | hahaha | 13-Mar-09 5:12 |
| 823 | Ammon | LOL, 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 |
| 822 | Maxim | I 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 |
| 821 | Maxim | from 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 |
| 820 | Ammon | c: liquify !color | 13-Mar-09 5:06 |
| 819 | Maxim | use liquify first. | 13-Mar-09 5:06 |