World: r3wp

here

http://perso.orange.fr/rebol/galaga.r

it's a try

fully bugged

and slow

my god... galaga was my favorite app back then  :-)

it's emulate an old game Galaxian

or Galaga

done with

Rebol

you're completely nuts !  :-)

yes i wrote a parser to convert Z80 opcodes into rebol instructions

it's just a try

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.  :-)

yes but to achieve this project and doing a real emulator, i need 
rebcode

currently it's to slow

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  :-)

thanks

did you try the rebcode version?

no

hummm should change group... polluting the liquid group...

i mean yes

a little bit

moving to chat

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

by a very fast scan... this pretty much sums up liquid.

;-)

have you tried liquid?

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

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"  ;-)

 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

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"

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.

glob glob glob !