r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!Liquid] any questions about liquid dataflow core.

Steeve
16-Feb-2007
[251]
not for the music
Maxim
16-Feb-2007
[252]
wow, you really are having fun!
Steeve
16-Feb-2007
[253x5]
here
http://perso.orange.fr/rebol/galaga.r
it's a try
fully bugged
and slow
Maxim
16-Feb-2007
[258]
my god... galaga was my favorite app back then  :-)
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
[298x3]
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.