World: r3wp
[!Liquid] any questions about liquid dataflow core.
older newer | first last |
Maxim 8-Mar-2009 [783x6] | will also make sure that my reply to your original question (built a little example in my tutorial folder) also is functional |
almost done... | |
version 0.7.1 released on rebol.org. | |
so, working now? | |
!color: make !plug [ valve: make valve [ type: 'color ;----------------- ;- process() ;----------------- purify: func [ plug ][ vin [{!color/purify()}] if integer? plug/liquid [ ; convert integer to b/w gradient plug/liquid: to-tuple head insert/dup copy [] plug/liquid 3 ] unless tuple? plug/liquid [ plug/liquid: 0.0.0 ] vout ; this is ESSENTIAL determines if plug is dirty or not... basically ; if you return false, the node stays dirty... and is re-evaluated everytime. ; if you forget to return a value, liquid causes an error. true ] ] ] print "----" c: liquify !color fill c 255.255.255 probe content c fill c none probe content c fill c 11 probe content c p: liquify !plug link/reset c p ; /reset is used to reset the state of the plug as ; virgin plug before linking. (all links removed, ; pipes and containers are forgotten/ignored) ; if /reset isn't used, the plug c WILL be linked ; but its links are ignored, since the plug is fill p 55 output: 255.255.255 0.0.0 11.11.11 55.55.55 | |
oops missing last probe in the above: probe content c | |
Ammon 8-Mar-2009 [789] | Yes, my code is working but it's capable of a bit more than that... |
Maxim 8-Mar-2009 [790x2] | do you understand the example I give? |
btw purification always occurs after processing... which is why it uses plug/liquid directly... at that point any processing would have occured... if any | |
Ammon 8-Mar-2009 [792] | Yes, I understand it. I'll be modifying my code to use both process() and purify() as I'm currently capable of linking multiple plugs to !color to set r.g.b separately and I need process for that but purify to ensure I have a tuple. |
Maxim 8-Mar-2009 [793x2] | that's exactly the point of separating them :-) |
btw adding node freezing, a very fundamental change to the engine, took a huge 4 lines and about 40 bytes to implement! | |
Maxim 9-Mar-2009 [795x3] | announcing stream ! I am in the midst of adding some more functionality to liquid which allows it to act as a signal processor (push method data-flow) the nice thing is that its incorporated in the same plug, again, and using message stream will retain 100% compatibility with all the current plug featureset. |
this will allow us to use window events directly within a lazy computing environment, for example, or provide dependency notification of child to parent changes. this will allows a node to send a manual signal "downstream" and possibly take processing/setup decisions based on those messages. downstream nodes should be able to return data in order to feedback the effects of the signal to its author, which might then, also activate some code. | |
so for liquid, this means a processing decision can be based on downstream nodes capability to handle it, its like look-ahead processing | |
Robert 10-Mar-2009 [798] | Max, you should take a look at petri-nets. I'm sure it will give you a lot of inspiration. |
Josh 10-Mar-2009 [799] | Woohoo, finally starting to make some progress with my comprehension of !Liquid! |
Maxim 10-Mar-2009 [800] | And I'm building up a lot of code and information for creating tutorials :-) |
Ammon 13-Mar-2009 [801] | I'm finding myself writing standard test code for each plug type as I go along and I was just thinking it would be nice if I could add the code as a block on the plug such that I could test any plug type by calling liquify/test !plug Or something like that... Could be a nice documentation/usage example feature. |
Maxim 13-Mar-2009 [802] | that is a Tremedous idea. I even know how It could be done... be carefull I might put you in charge of developping it :-) |
Ammon 13-Mar-2009 [803] | Sounds good to me! |
Maxim 13-Mar-2009 [804] | As you know, I just totaly reviewed how liquid-vid will handle its layout (now a live prodecural network in its own), so I am hard at work building that, but I will definitely put some time on integrated unit testing, when I rebuild the visual graph editor. its such a great idea, as we have discussed, the I/O aspect of plugs cannot be ignored in dataflow, so this would be a great way to profile, document and verify expected node behaviour. |
Ammon 13-Mar-2009 [805] | BTW... I seem to be seeing a node processing it's liquid when it shouldn't be. Once a node is liquified, filled and purified it shouldn't call process() or purify() again until it is filled again, should it? |
Maxim 13-Mar-2009 [806] | this and the !plug/document. |
Ammon 13-Mar-2009 [807] | I really can't wait to play with liquid-vid. |
Maxim 13-Mar-2009 [808x3] | btw there is already a plug/valve/stats feature embedded within, which gives you the node's current state and setup. |
btw, the work being done for liquid-vid's layout, is now the official prototype for the inital layout engine for GLASS | |
although GLASS will use the data within AGG instead of view/faces. | |
Ammon 13-Mar-2009 [811] | Hrm... Accord to stats my node is still dirty although I KNOW I am returning TRUE from purify() |
Maxim 13-Mar-2009 [812x3] | so after 15 years of analysis, design and countless prototypes of all shapes and sizes , I am now finally working on the first true code that will find itself into some layer of the GLASS engine. =oD |
you called content on the plug before calling stats? | |
(content is a duplicate word for the cleanup function) | |
Ammon 13-Mar-2009 [815x2] | Yup! |
!color/process() [ ] !color/purify() [ ] 0.255.75 0.255.75 (should be) >> c/valve/stats c liquid/color[1]/stats [ ================ PLUG STATISTICS: ================ LABELING: --- type: color category: !plug serial id: 1 LINKEAGE: --- total subordinates: 3 total observers: 0 total commits: 0 VALUE: --- tuple!: 0.255.75 INTERNALS: --- pipe?: none stainless?: false dirty?: true shared-states: linked-container?: false mud: 1.2.3 ================ ] >> c/liquid == 0.255.75 >> content c !color/process() [ ] !color/purify() [ ] == 0.255.75 | |
Maxim 13-Mar-2009 [817x3] | i don't know a part from you forgetting to liquify the plug first what could be going on! |
that's a class... not an instance. | |
use liquify first. | |
Ammon 13-Mar-2009 [820] | c: liquify !color |
Maxim 13-Mar-2009 [821x2] | 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. |
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! | |
Ammon 13-Mar-2009 [823] | 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 |
Maxim 13-Mar-2009 [824x2] | hahaha |
yep... I WILL | |
Ammon 13-Mar-2009 [826] | Fixed. Sweet! |
Maxim 13-Mar-2009 [827x2] | strange I can't find that specific code in blood.r... I guess I already fixed here, hehe. |
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! ;-) | |
Ammon 13-Mar-2009 [829] | LOL |
Maxim 13-Mar-2009 [830] | 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... |
Ammon 13-Mar-2009 [831x2] | Oh, my bad. It's not in Blood.r. It's in the code you posted above for the !color node... |
Congrats! | |
older newer | first last |