World: r3wp
[!Liquid] any questions about liquid dataflow core.
older newer | first last |
Steeve 16-Feb-2007 [259x4] | it's emulate an old game Galaxian |
or Galaga | |
done with | |
Rebol | |
Maxim 16-Feb-2007 [263] | you're completely nuts ! :-) |
Steeve 16-Feb-2007 [264x2] | yes i wrote a parser to convert Z80 opcodes into rebol instructions |
it's just a try | |
Maxim 16-Feb-2007 [266x3] | you should have done so for a C64! we'd have 100000 rebol games!!! |
;-) | |
its actually quite functional... there are a few gfx issues... but its REALLY cool. :-) | |
Steeve 16-Feb-2007 [269x2] | yes but to achieve this project and doing a real emulator, i need rebcode |
currently it's to slow | |
Maxim 16-Feb-2007 [271x2] | obviously. |
its actually not too bad on my pc... but it just crashed on me... nevertheless I am very impressed by your attempt... its already very good :-) | |
Steeve 16-Feb-2007 [273] | thanks |
Maxim 16-Feb-2007 [274] | did you try the rebcode version? |
Steeve 16-Feb-2007 [275] | no |
Maxim 16-Feb-2007 [276] | hummm should change group... polluting the liquid group... |
Steeve 16-Feb-2007 [277x2] | i mean yes |
a little bit | |
Maxim 16-Feb-2007 [279] | moving to chat |
Mchean 27-Feb-2007 [280] | Maxim: I know at one point you were looking at Sentences and the associative model. This sounds similiar: http://www.pilesys.com/new/news.php |
Maxim 27-Feb-2007 [281x3] | by a very fast scan... this pretty much sums up liquid. |
;-) | |
have you tried liquid? | |
Mchean 27-Feb-2007 [284x2] | just cursory, i need to familiarize myself with rebol a little more |
you look like you are getting a lot of good mileage out of it though | |
Maxim 28-Feb-2007 [286x7] | so far its exceeding my expectations. although not dialected, the engine itself is very pliable and the lazy computing seems to pay off in general. |
liquidator is a good test bed for the engine, and so far, I have changed nothing in the design of liquid itself, I just keep improving how I link stuff and manage the liquid nodes themselves. | |
also, the fact that symmetric piping and dependency trees can co-exist with such triviality makes integrating GUI within networks really easy so far. | |
what I am realising is that dataflow driven computing is more complicated to implement, but vastly superior in its ability to survive changes. Things like state changes or sequence-based computing is harder to implement, cause you have to explicitely manage states, in which imperative style, you just don't realise the FSM within. | |
so... its a bit tough at first, cause you can't just go in and start off quickly... especially since some coding practices have to change to adapt to the paradigm... but in the end, you have no cleanup phase. so its a fair tradeoff... | |
I implemented a simple session login with a neophyte on this list... and it was a good learning experience for both :-) | |
Like I told him " I made it, I understand it ... I just don't know how to use it" ;-) | |
Mchean 28-Feb-2007 [293x2] | I made it, I understand it ... I just don't know how to use it :D |
I can relate to the second half of that statement | |
Maxim 28-Feb-2007 [295x3] | it just turns programming upside down and you have to think so differently that some impossible things are just plain trivial, and stupidly easy things become a design nightmare! |
Its just cool that you can't leave any loose ends hanging around... otherwise the system just doesn't work. | |
just like you can't just leave a gear loose inside a car's transmission for "whenever it might be needed" | |
Maxim 3-Mar-2007 [298x4] | hehe I just realised that my graphic toolkit is very transparent... I have this line in my code: clear gel/liquid |
Just did a little research on programmatically controled I/O blocking (on demand) for a liquid node :-) this is very powerfull as it allows you to trigger your node's messaging only when some of the inputs are in specific states. making the engine able to prevent downstream nodes (observers) from knowing about upstream data changes, when they are not usefull. | |
also since we have explicit knowledge of dirtyness of data, we can block I/O explicitely before or after some inputs have processed... so if you have a 'hide state for example, actually changing that state can send (or not) an update, so that the other inputs get used when it un blocks... and any one needing the value, will get the modified values, which where stored while the node was blocked :-) no data is lost, its only dormant. | |
applying this to a gui driven with liquid nodes, you could freeze the the whole layout on a modal window... and let your inputs continue to process in the background... updating animation, and reacting to async reads... for exacmple. when you unfreeze the gui and call a refresh of the gui plug, all the data which was being processed in the background, is now automatically available ,as if nothing had been frozen and a simple update of the node, will refresh you gui with nothing to manage. | |
Steeve 7-Mar-2007 [302x2] | glob glob glob ! |
demo ? | |
Maxim 7-Mar-2007 [304x2] | did you try out the regraph engine? |
it has a primitive version of the glob engine. It has grown since, but keeps the same basic idea. | |
Maxim 7-May-2007 [306] | AS A TEASER FOR DEVCON... HERE IS THE FIRST EVER PUBLIC SCREEN SHOT OF ELIXIR ! http://www.pointillistic.com/open-REBOL/moa/steel/elixir/elixir_0_3_5.png |
Anton 7-May-2007 [307] | Those nodes look really nice. |
Maxim 7-May-2007 [308] | thanks :-) took a bit of tweaking to get the stuff sorted out, but I'm starting to get the hang of AGG. |
older newer | first last |