AltME groups: search

Gabriele, liquid (dataflow) adds a level of stability to any project. 
 the fact that its lazy pays off very well so far.

I have gone through 3 rewrites before hitting this sweetspot.  other 
versions might have been simpler in a way, but left the system, non 
generic and unscalable in one of many different ways.

liquid's strength lies in the fact that it is generic.  we all write 
dataflow within our applications, without realising it.  but we then 
recode each little system in its own isolated architecture.  this 
means we just loose a lot of time.

and in fact, if we do add a measure of reflexivity to VID, we will 
just be redoing most of liquid, or run in the same issues, I had 
in my other prototypes, which led to this design.   ;-)

but we will not gain the advantage of having generic dataflow!

the only difference is that some (switcheable in real time, even 
set to a function) which will always want to refresh, when they are 
aware of data changes.

when you move a slider that is attached to something, is that something 
that has to pull? does it pull x times a second?

 does it pull x times a second?

that is up to you to decide, really.

at a high level yes.  but in reality, no.  if you have some gadgets 
or other parts of dependent systems which do not "need" the value, 
it might not cause any refresh.

but you are only seeing all of this as a VID thing.

especially since its such a small kernel !  (not the current implementation, 
which has a few prototypical stuff left)

you see, if we had a dataflow datatype, we would not even need to 
talk about "do we add this to VID"  people could just set values 
to attributes which are DF based.

hum liquid is what 50 kb of 0% optimised code.  DF its a data processing 
kernel, paradigm level feature.. quite different in scope.

Hi Max, reading the %liquid.r source code from rebol.org, I've found 
a typo at line 948 : count plug/subordnates object!  (i missing in 
"subordnates").

Hi doc, The version of liquid on line is not quite the latest (obviously)... 
 but I'll check out your info... its possible that one was already 
fixed.... I fixed a few minor bugs  since I last released.  Mainly 
due to intense use within glob and elixir.

dideC: well, I'm am working towards that.  I am keeping up the habit 
of working on one thing at a time and currently I'm hard at work 
on Revault.  that being said... guess what are the first libs to 
be put online  ;-)

elixir is a proof of concept generating application... I am still 
measuring how well the generalised use of Liquid in all aspects of 
an application equate to all of my claims, but so far, empiricaly... 
it seems to be keeping up the intended benefits.

unfortunately, demo apps are still not available.  One person using 
liquid is making a for profit dentist EMR and scheduling app.  there 
is elixir, and there was the original liquified draw dialect example 
I had released just before the new year.

I have a pretty nifty parse-rule generating application which uses 
liquidGL but its far to complex to be used for understanding of anything.

elixir already has that built-in to its values, so any gadget also 
inherit their "flawlessness" but its not something that jumps at 
you... its a subtle but oh so important detail.

so, my answer to DideC, I guess, is:  

Give me ideas on simple demo applications I can build ! 

And I'll consider which one I do first.  :-)


 I need and want this info to make the whole package more appealing 
 and comprehensible.  The current uber simple Sum example, just gives 
 a glimpse of the engine's capabilities, not of its application.

I'd need a bit more explanation of what you mean by that.

basically a connection based TCP i/o interface to any liquid network. 
 you define the ports, the protocol (on either end) and can then 
interface your Dataflow across machines  :-)  it would allow distributed 
processing without any understanding of such concepts.

obviously, the standard issues of machine redundancy will arise, 
but that is a good exercise for the later revisions of the system.

so one (actually several)  machines can be a controler and synchronise 
to others which can also locally change their states... and whatever 
they data can generate can be sent to any other machine, including 
the controlers... so you have ONE kernel to handle all aspects of 
your systems.  and its dead easy... and would interface directly 
within any other liquified systems like liquid GL, elixir, globs, 
or eventually GLASS.

want text ports, just make a liquid which spues out text on the console... 
need that logged, just plug in another node which spues out stuff 
on disk as it comes in... but you don't even have to change anything 
in your systems... and can even easily connect your logger to other 
nodes, so you can track the flow of traffic, or the end effects some 
root events are having on the outputs of the system.  sometimes its 
not obvious to see the real world relation of inputs and output... 


liquid allows you inspect all states at all points in time of you 
system's processing and compare it.

Maxim, I don't know if this would be considered simpe, but here is 
a suggestion:
http://www.bliner.com/projectmanagement.html

Max, on of the best examples would be a Rebol based simple 20x20 
Excel clone. Let people use Rebol code in the cells, and handle the 
reference handling via Liquid. It should be perfect DF applicable.

robert, If I start from scratch, it will be an n dimension spreadsheet 
with a scale of infinity in each of those dimensions (thus really 
limited by RAM, disk and REBOL types).   why start it up with a limitiation 
which is actually very easy to design correctly for starters... 


especially with GLayout which would just adjust the views as they 
grow.

ok.  can it be packaged as a library module  ;-)  I'd put it up on 
revault

(just started looking at nanosheets... must have a little fun)

hum... I'm thinking its going to be much easier to make a pico sheets 
 ;-)

I'll pipe in...I've got a modified copy of nanosheets with scroll 
bars so it could support

more cells for financials sheets for the Fire Deparment volunteers...

I've started a simple test... but will start over... the new version 
will handle as much cells as you have RAM  :-)

basically going to use a HASH of liquid nodes (the nodes themselves 
being already connected) and just asking for cell values, based on 
what cells are visible within the scrollpane.

although it looks like he hasn't been on for a while

Max posted this to the mailing list about a month ago:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlFGXC

Max lives in a world of his own ... and I don't know the address!

I've been using liquid in a variety of projects for the better part 
of 2 years now... its ubber stable, fast and quite scalable... in 
fact much better than I had anticipated, for such an un optimised 
piece of code.

There were a number ... I can remind you if you like :)

elixir, for example,  easily allocates 10 000 nodes, creates a several 
thousand line AGG script and actually manages to rebuild the whole 
AGG dialect block faster than view can redraw it.

You should be a salesman

elixir builds a 100% native AGG GUI .   EVERYTHING is built using 
liquid, event the field (control) properties and cursor management.

elixir is a next generation Operating system.

I havent done the OS level UI, just the work area system... but the 
OS level GUI is a piece of cake.  basically, just an interactive 
browser of your data cloud, using the query language and user d specified 
tags and information classification.

do a movie and let us see what you've got ...

hehe but it was bought up by a german company

the latest game graphics are simply amazing.  I've seen a real time 
strategy game with hundreds of characters which have reflecting armor... 
I mean the armor is inter-reflecting amongst characters!  this is 
starting to be pretty amazing.

could also be a damned VISTA issue.

Just a ploy ... to make us upgrade our hardware

anyhow... during the holiday season, I will be putting A LOT of time 
on my coding... so maybe, I'll release some stuff.

working a lot on remark right now...

yess its already on rebol.org... its not a visually driven engine, 
though, if that's what you are looking for.

the visual node work engine is my other (large) project, called Elixir 
... its a node-driven work environment.   Elixir is not yet ready 
for public scrutiny as its just a few percent short of being usable.

I finally started playing around with liquid.r   Having a little 
trouble conceptually with converting code that contains objects into 
the data-flow model.  For example, I was fiddling around with a D&D 
character generator.  I have an ABILITY! object class that I'm trying 
to convert to the model now.  SUM is just a function that adds up 
all the values in a block


ability:  [[1 -5] [2 -4] [3 -4] [4 -3] [5 -3] [6 -2] [7 -2] [8 -1] 
[9 -1] [10 0] [11 0] [12 1] [13 1] [14 2] [15 2] [16 3] [17 3] [18 
4]]
ability!: make object! [
	base: 0
	modifiers: [0 0]
	total: does [base + sum modifiers]
	ability-mod: does [ability/(total)/2]
]


It may be a lot to ask, but would it be possible for someone to convert 
this to liquid, so I can actually see how one creates this kind of 
hierarchy in data flowprogramming.

the !sum plug is a good example,but I get a little stuck beyond that. 
 From my first impression of trying to do this, it seems like I'm 
going to have to define so many variables to make it too troublesome. 
 But I'm sure that I'll have to learn how to think in the right way 
to avoid all that

whoops, base needs to have a value above 0 in that example

well only to handle the edge of the graph, since the computer/OS 
isnt't running within a graph

I did  a D&D character manipulation application once when prototyping 
liquid, so I understand exactly what you are trying to do  :-)

josh, did you try out the tutorial?  the example is a basic sum node. 
 although its not exactly what you need for the above example, it 
should give you an idea of the lego-style building of a liquid network.

Max, I still wait for a simple to follow example and some simple 
to follow docs.

Josh: for simple data compilation and changes (like a D&D character 
creation/evolution), I suggest writing an aspect-oriented type of 
node set for your  application.

basically, how this works is, you have a generic object which you 
pass around from node to node.  each node may add/display/change/remove 
one or all of the attributes in the objects.  


Just plug some aspect-managing node to your "current" node and that's 
it, over and over.   Its as easy as calling a function on an object. 
 the difference is that all states of your character are still available 
up till its creation. 


 you can even branch off at any point and try out another combination 
 with NO risk of corrupting your previous data.

the trick is to implement the "rules" within the aspects themselves. 
basically returning some kind of error (or warning) when some rule 
is broken within a node.  (going above some limit, impossible selection 
based on race, etc)

hum I just did a bit of googling for it ... can't remember ... IIRC 
a few good references on wikipedia.

But a more complex example would be very helpful, otherwise I'm dead 
in the tracks

but I have spent many hours using liquid, testing it prototyping 
it, and even building an OS Operating Environment with it...and I 
now know its a viable idea.

I'll build up a quick and dirty aspect-driven, character creation 
tool  :-)

with a gui.

I also have a simple graphics package which uses AGG directly with 
liquid, so I'll use that to further show liquid ties in from end-to-end.

SOunds great!  If you can't get it finished, at least show me a sizable 
component of it so I can get some ideas

what I'll do is post all of this on rebol.org, so the whole world 
gets  a view of it  :-)

I have a double set-back though... the old aspect code was for a 
previous version of liquid...

hehe, yeah, I'm starting to finally fix all my poor coding practices, 
especially with naming.   Anyways, sounds good,  again, you don't 
need to do the whole char gen or anything, but just a good chunk 
for me to see how to put things together

strange, cause its a static html page ... just one or two table.... 
in this case... I must say that opera seems to be the issue  ;-)

did you try reloading the page?

btw wrt the old code, I realised the issue... I had cleaned up the 
lib, and stopped half way....   so the naming changed, a few features 
missing... :-(

ok, so I have something to send to you... what I have is not really 
usefull to send to rebol.org without any kind of discussion, documentation. 
 I did something different than expected.  I just built a simple 
dataflow driven fsm engine which switches aspects on demand.  then 
I defined aspects which operated on a face, and made a very simple 
feel which sets the various states.

the dataflow takes care of calling any aspect which are built up 
from linked nodes.  basically, you build up a stylesheet by connecting 
nodes together and can branch off at any point, simply reusing the 
previous styles as a base... the cool thing is that the styles aren't 
absolute, you can define more than one style for a single state, 
so that a series of nodes can handle only the edge, others the color, 
yet you can include both in another style  (in my case, the base 
style has both)

I'll add a few more aspects to the system to show how this all scales, 
tomorrow and send you a copy.   :-)

next step will be to add some data to manipulate... I'll do a character 
attributes builder.  all 6 stats with a +/- counter besides each 
which you press and all the display magically adapts, even stopping 
the buttons when out of range, or no more points to attribute   :-)

Sometimes I wish there was a delete button for messages I type, got 
some dumb ones from time to time

hehe, while working on stuff, I suddently entered one of those rare 
brainstorming states... so I've basically been in my mind for the 
last 3 days... but I now have a nice roadmap for something that will 
help me to make clear examples or liquid.

ok, so I have a bit of spare time tonight and will build you a stand-alone 
example of a small RPG character editor.   Using !plug objects directly, 
so you can see the process of subclassing the core plug to have it 
do something usefull.

did most of the work yesterday, and will revise it to use VID.  it 
just going to take a little less code.  I think.

its already working, but will add a few gizmos to give it more depth. 
  liquid makes more and more sense, as an application grows.


so adding a few features will show you how simple an application 
remains, even when many things interdepend.

it will definitely be available tonight.  btw, I found and squashed 
a little but in liquid, so will also release a newer version on rebol.org 
when I release the example.

I am now in the process of adding a skill editor (note, not in any 
way a valid D&D chargen, just a simple example to understand by anyone).

will also add a little integrated lib downloader.... to make it extra 
easy to use.

the code isn't intended to be compact... the goal is to help people 
understand.  I added a few comments which explain what/how/why some 
of the things.

I might also add a doc to explain some of the unobvious technical 
merits of the example.  people can say: "All that code just for that?" 
if they don't understand what is going on.

liquid R3... it could go really well, as it could be a bitch... if 
one little detail in a function breaks up the integrity of the whole.

You have such a strange way of wording things some times.  "broken 
code doesn't work, the side effect is that working code is unbreakable" 
 I'm not really sure what that means...

hehehe... means a system doesn't work at all until it does... and 
from that point on... its almost impossible to mess up.

you just move on, and forget what has been done so far.  adding stuff 
to a system, doesn't mean patching old code.  it simply means tacking 
new systems to the old, and deciding how they relate.

the application will be there within the hour (need to build a friendly 
little rebol.org based slim lib D/L interface using VID)

Interesting...  I'm a heavy prototyper.  I need one statement that 
does something to start with and I often have to see each additional 
statement functional before I can move on to the next.  If I spend 
enough time within a given environment I'll eventually be able to 
rebuild it from scratch but your code has always been deceptively 
simple so I often need an explanation of why you do what you do how 
you do it.

I added such comments throughout the code, it should be a pretty 
easy to grasp example, me thinks  :-)

I'm REALLY happy to do it.  its a great opportunity for me to actually 
get some limelight on liquid  :-)

I'll build a second version which has a skill editor  :-)

also note that liquid was NEVER optimised, so if you look at its 
code, you might find slow loops and such... I know!  for me, having 
it work without bugs and making it easy to maintain, is more important 
than raw speed... in all apps I've done using it, a single View face 
refresh slowed down the application more than alll liquid nodes combined, 
so the integrated lazy computing does enough optimisation on its 
own to make raw optimisation less of an issue.... but when I decide 
to go v2, I will make a "fast" version of the tool for production 
purposes... indentical in features, but with debugging removed and 
some loops optimised for speed.

the shared class, already speeds up the memory handling of the GC 
by a factor of 20 or 100 based on the size of your application (exponentially 
faster, as the app grows)