World: r3wp

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 !

demo ?

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.

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

Those nodes look really nice.

thanks  :-)  took a bit of tweaking to get the stuff sorted out, 
but I'm starting to get the hang of AGG.

Yes, looks good.  


May I suggest doing a "bright version" (white BG...etc.  As if Mac 
designed this...)


Although the dramatic colours always look striking, in the long run 
people tend to prefer the light colours so that they can use them 
easier in print and slide shows.

thanks!


yes, its always a matter of user useage, in the graphic editing world 
all the high-end apps use a dark scheme...

Maxim - what will Elixir enable us to do? :-)

but the colours are totally editable... it might take a few initial 
releases before I allow them to be editable in the API but internally 
all of that is very easy to change.

Elixir is a first shot at redefining the concept of you workspace.

you=your

I'm using a node graph as the basis for ALL system operations.  for 
now, I'm just finishing the core framework, so the "tools" part is 
not yet in place, but I'll have a nice demo to open up the future 
of elixir.

sounds cryptic to me - could you provide me with the example usage?

I'll ask a question... what do you do on your computer?  well that 
is all of what elixir will be able to do once all the elements are 
in place.

watching video, editing photos, chatting on icq, altme, a little 
bit of rebol coding, browsing web :-)

the difference is in the loss of the "software" as a monolithic entity 
which modify files.

now imagine being able to do all of those things together... litteraly. 
 any exchange of data can go to any other process.

hmm, could it be used e.g. for rebol programming? e.g. each node 
would be your module? hehe, kind of cool IDE for rebol :-)

and in fact, using elixir, many of the traditional need for "standard 
comms" becomes irrelevant as you build up apps on the fly, exactly 
as you need them.

the second module I'll be building for elixir. is a rebol IDE.

or even a menu system ... would look cool in 3D, openGLed :-)

each node can be anything... a code block, a text prepropressor, 
a function def.

yep... waiting for R3 ... but the core engine can work over any GUI 
cause its decoupled.

the cool thing is the cross application capabilities.... need to 
insert a pic in a button... hum.. just use the output of the image 
creating node and plug it in the image input of a button.

also note that currently, its 100% AGG/

well, whole new View is 100% AGG :-) Cyphre switched compositing 
engine to that of AGG internally AFAIK

I know... and the gobs, match conceptually my globs... funny how 
the naming even got to be almost the same.

I can say I have probably helped Cyphre into a few decisions, which 
are old requests of mine.

so if its done Like I think, using R3 elixir should be VERY interactive. 
 and if that doesn't work, well, I can just use OpenGL later on.

(well elixir is already pretty smooth... much more than I would have 
anticipated... especially with so little in the way of optimisation 
so far)

nice ....

(obviously, liquid's lazy computing goes a long way into that.)

I am curious, what Carl has in mind for View ... there were view 
plug-ins planned (dunno if it is the same concept as "rebol language 
plug-ins"?), which were supposed to provide you access to loaders, 
savers, and maybe even buffers?

it is good we saw some interview with Carl. It was talked on 3 forums. 
With R3 release, we could continue in that kind of "marketing", with 
some nice demos etc.